How to File an SLA Service Credit Claim (Step by Step)

1. What a service credit is (and is not)

An SLA (Service Level Agreement) is a written promise about service quality — often uptime. If the provider misses that promise, many contracts offer a service credit.

In simple terms: a credit is usually money off a future invoice, not cash back to your bank account. The size often depends on how far below the target you fell (credit “tiers”). Some contracts also set a monthly maximum.

• Is: a contractual remedy described in the SLA or MSA.
• Is not: automatic compensation for every bad day, unless the contract says so.
• Is not: a replacement for measuring business loss. Credits and downtime cost are different topics.

This guide helps you prepare a clean claim. It is planning help — not legal advice. Always follow the exact text of your vendor agreement.

2. Before you start

Collect these facts first. Missing one of them wastes time later:

1. Provider name and product / service ID (subscription, project, account).
2. The promised uptime % (for example 99.9% or 99.95%).
3. The measurement period (often a calendar month — 28 to 31 days).
4. Where claims are filed (support portal form, email alias, account team).
5. The claim deadline (for example “within 30 days after the month ends”).

If you do not know the day count for the month, open calendar-month SLA downtime tables. If you need allowed downtime for day/week/year comparison, use the uptime reference.

3. Gather logs and a clear timeline

Good claims start with a timeline a stranger can understand in two minutes. Write events in order. Use one timezone (UTC is often safest) and say which timezone you used.

• Start and end times for each outage window.
• Monitoring screenshots or exported metrics (availability, error rate, latency if relevant).
• Vendor status-page links or incident IDs, if any.
• Your internal incident ticket IDs.
• Customer impact notes (optional but helpful): who could not work, which regions, which features).

Tip: export raw data when you can. Screenshots help, but CSV or monitoring export makes math easier to defend.

4. Check exclusions (do this before the math)

Many SLAs say some downtime does not count. If you skip this step, your shortfall may look larger than the vendor will accept — and the claim may be denied.

Common exclusion themes (wording differs by vendor):

• Scheduled maintenance announced in advance.
• Problems caused by your configuration, code, or credentials.
• Failures outside the provider’s control (sometimes including upstream internet paths).
• Beta / preview features not covered by the paid SLA.
• Force majeure events, when the contract lists them.

Make a short table: “minutes removed” and “why.” Honest exclusions make your claim stronger, not weaker.

5. Calculate the shortfall (open math)

Use the same formulas as our reference pages. Keep units consistent (minutes).

Then open your vendor’s credit tier table. Map the shortfall (or the achieved uptime band) to a credit percent of eligible charges.

For a quick planning estimate, use the SLA Penalty Calculator. Remember: the calculator is an estimate. Your contract tiers win.

6. Deadlines — do not miss the window

Most providers require you to claim within a fixed time after the month (or after the incident). If you file late, they can deny a valid shortfall.

• Find the deadline sentence in the SLA and put it on your calendar.
• File early enough to fix missing attachments if support asks for more data.
• If the portal is down, keep proof you tried (email to the published claims address, ticket screenshot).

Tip: start the evidence pack during the outage week, not on the last day of the claim window.

7. Build the evidence pack

Package materials so a support agent can approve without a long chat. One folder (or one PDF) with clear names works well.

1. Cover note (half page): account ID, month, promised %, actual %, shortfall, requested credit %, and estimated amount.
2. Math appendix: period days, period minutes, downtime minutes after exclusions, formulas used.
3. Timeline: dated outage windows in one timezone.
4. Monitoring exports / screenshots: labeled with the same times.
5. Exclusion log: minutes removed and reasons.
6. Contract citations: quote the uptime promise and credit tier section (page or clause IDs).

Optional: link to how you computed allowed downtime using TechImpact’s open methodology — useful when you need a shared language with non-engineers.

8. File the claim

Use the channel the contract names. Typical paths:

• Cloud console → Support → “Request service credit” (or similar).
• Named account manager email, with the ticket CC’d.
• A web form linked from the SLA document.

Keep the first message short. Put detail in attachments. Ask for a written confirmation number. Store that number with your finance team so the credit is not forgotten next invoice.

9. Escalate if needed

Denials happen. Escalate when your package is complete and the denial conflicts with the written SLA — not when you are still missing timelines or exclusions.

• Reply once with clarifications and the exact clause you rely on.
• If stuck, involve your account manager or commercial owner.
• Track days in queue; some contracts have dispute timelines too.
• Separate “we disagree on facts” from “we disagree on contract reading.” Ask which one it is.

If the credit is small but the outage was large for your business, still document it. Pattern evidence helps renewals and architecture decisions even when the credit is capped.

10. Worked example

In the evidence pack for this example you would attach: March day count proof, the 52-minute downtime sum, the 10-minute exclusion note, graphs for both incidents, and a quote of the 10% tier clause.

11. FAQ