How to calculate your SLA credit: the formula, worked examples, and the mistakes that zero it out

An SLA credit is worked out in three moves: measure the downtime, turn it into a monthly uptime percentage, and multiply the vendor's credit tier by the fee for the service that broke — not your whole invoice. The number most people get wrong is the first one, because a 99.9% SLA allows only about 43 minutes of downtime in a month, so an outage that felt minor often clears the bar for a claim. This guide walks the formula end to end, with a downtime cheat sheet and two worked examples, then shows the three situations where a genuine breach still calculates to zero.

The short answer

Credit = credit-tier percentage × the monthly fee for the affected service. The tier percentage comes from how far your measured monthly uptime fell below the vendor's committed uptime: most vendors pay 10% / 25% / 50% (or up to 100%) across worsening bands, a few pay a flat percentage for any miss, and a few pay nothing you can file for. It is a credit against a future invoice, not a cash refund, and every vendor puts a short deadline on it. The hard part isn't the arithmetic — it's measuring the downtime against the right month and knowing which part of your spend the percentage applies to.

How to calculate your SLA credit

1. Pull the exact incident start and end timestamps from the vendor's own status page — not from your internal alerting — and add up the total minutes of downtime that fell inside the affected calendar (or billing) month.
2. Convert downtime to an uptime percentage: uptime = (total minutes in the month − downtime minutes) ÷ total minutes in the month × 100. A 30-day month is 43,200 minutes; a 31-day month is 44,640.
3. Compare that uptime to the vendor's SLA commitment. If it meets or beats the commitment, nothing is owed; if it falls below, you have a claim.
4. Match the uptime to the vendor's published credit tier to get the percentage (for example 10%, 25% or 50%), or apply its flat rate.
5. Multiply that percentage by the monthly fee for the affected service only — not your whole bill — and file the claim before the vendor's deadline.

Converting uptime to downtime (the number most people get wrong)

Uptime percentages compress a lot of tolerance into a few decimal places, and the gap between "sounds fine" and "owed a credit" is small. Here's what each common commitment actually allows in a single 30-day (43,200-minute) month:

The takeaway: at 99.9% and above, outages that felt forgettable often cross the line. If a vendor committed to 99.95% and was down for 40 minutes last month, that's already a breach — 40 minutes against a 21.6-minute budget — and a claim you can calculate. This is the same downtime budget we break down in detail in what a 99.9% SLA actually allows, and the measurement method behind it is in how your SLA is actually measured.

Match your uptime to the vendor's credit tier

Most vendors publish a tiered schedule: the further below the commitment you fall, the larger the percentage. Google Cloud's service SLAs are a clean example of the common shape — the credit is a percentage of the monthly bill for the affected service:

Ontracko reads these bands as *up to but not including* the upper figure, because exactly at the commitment there is no breach and nothing is owed. The exact percentages and cut-offs differ by vendor — Atlassian tops out at 50%, AWS, Azure and MongoDB Atlas reach 100% in a catastrophic month, and Twilio pays a flat 10% — so always match against the specific vendor. You can see each vendor's committed uptime and tier table, and estimate your own amount, on its SLA page, e.g. Google Cloud, Atlassian or MongoDB Atlas.

Worked example: a tiered credit (Atlassian)

Say Jira Cloud Premium (committed to 99.9%) had a 90-minute outage last month, and your Jira fee is $2,000/month.

• Downtime: 90 minutes in a 30-day month.
• Uptime: (43,200 − 90) ÷ 43,200 × 100 = 99.79%.
• Breach? 99.79% is below the 99.9% commitment — yes.
• Tier: 99.79% sits in the 99.0%–99.9% band → 10%.
• Credit: 10% × $2,000 = $200, applied to a future invoice.

Atlassian's window is the tight part: the claim is due by the 15th of the month after the outage, and it requires a support ticket raised *during* the incident. The full process is in how to claim an SLA credit from Atlassian.

Worked example: a flat credit (Twilio)

Twilio doesn't tier. Its messaging/voice SLA commits to 99.95% and pays a flat 10% of the affected product's monthly fees for any month that misses it — the depth of the breach doesn't change the number.

• Downtime: say 40 minutes in a 30-day month.
• Uptime: (43,200 − 40) ÷ 43,200 × 100 = 99.907% — below the 99.95% commitment, so it's a breach.
• Credit: flat 10% of that month's affected Twilio service fees. On $5,000 of messaging spend, that's $500 — and it would be the same $500 whether you were down 40 minutes or four hours.

One catch specific to Twilio: the 10% applies to Twilio's own service fees, not the carrier pass-through fees bundled into your bill. Details in how to claim an SLA credit from Twilio.

When the math says you're owed nothing

A real outage doesn't guarantee a calculable credit. Three situations produce a legitimate breach with no filable number:

• AWS and Azure region vs. instance. The headline region SLA typically requires *all* availability zones to be unreachable before a credit applies — a single-AZ or partial outage, however painful, often clears nothing. Where instance/VM credits do apply, they're frequently auto-applied with nothing to file. See AWS and Azure.
• No published tariff. Salesforce publishes no standard credit schedule — any remedy lives in your own MSA, so your percentage is whatever you negotiated, not a public table (does Salesforce pay SLA credits?). Datadog's standard agreement pays no service credit at all; the only remedy is a termination right after sustained misses.
• A formula public data can't fill. Cloudflare's core SLA is a multiplier keyed to the ratio of *affected* customers, a figure its public status page doesn't expose — so the breach is real but the amount isn't computable from outside your account (how to claim from Cloudflare).

This is why "I was down, so I'm owed X" is unreliable: the credit depends on the vendor's exact model, and a wrong assumption is one of the six reasons claims get denied. For the vendors that genuinely pay cash-equivalent credits, see which SaaS vendors actually pay SLA credits.

Frequently asked questions

How do I calculate my SLA credit?

Add up the downtime minutes in the affected month, convert to an uptime percentage with (minutes in the month − downtime) ÷ minutes in the month × 100, check that it's below the vendor's committed uptime, then multiply the matching credit-tier percentage by the monthly fee for the affected service. The result is a credit on a future invoice, not a cash refund.

How much downtime does a 99.9% SLA allow in a month?

About 43 minutes in a 30-day month (0.1% of 43,200 minutes). That's why a single ~45-minute incident can breach a three-nines SLA. At 99.95% the budget is roughly 22 minutes, and at 99.99% just over 4 minutes.

Am I owed an SLA credit if my vendor was down for 2 hours?

It depends on the commitment and the month. Two hours is 120 minutes, which breaches any SLA of 99.9% or stricter in a single month — but whether you can file for it depends on the vendor's model: a tiered vendor would likely owe 10%–25% of that service's fee, while AWS/Azure region SLAs may owe nothing unless all availability zones were down.

Is an SLA credit a cash refund?

Almost never. SLA credits are applied against a future invoice for the same service, are usually capped at a fraction of that month's fee, and expire if you don't claim them in time. They reduce what you pay next; they don't put money back in your account.

What's the difference between a tiered and a flat SLA credit?

A tiered credit grows with the severity of the breach — e.g. 10% near the commitment, 25% lower, 50% or 100% in a catastrophic month. A flat credit (Twilio, for instance) pays one fixed percentage for any miss, regardless of depth. Tiered schedules reward documenting exactly how bad the month was; flat ones don't.

Why does my SLA breach calculate to zero credit?

Usually one of three reasons: the outage didn't meet the vendor's definition of downtime (e.g. only one AWS/Azure AZ failed when the SLA requires all of them), the vendor publishes no claimable tariff (Salesforce's negotiated-only terms, Datadog's no-credit MSA), or the credit depends on account-specific data a public status page can't supply (Cloudflare's affected-customer multiplier).

Methodology & caveats

The commitments, credit tiers, and flat/multiplier/none models referenced above are transcribed from each vendor's published SLA into Ontracko's vendor profiles; the downtime figures are arithmetic against a 30-day, 43,200-minute month. Calendar and billing months vary in length, several vendors measure over a rolling 30-day window rather than a calendar month, and your order form may override the public terms — so verify the exact clause, period and your plan before filing. Credit tiers, deadlines and definitions change; check the vendor's current SLA, or let Ontracko track it for you. Start with what an SLA credit is, the deadline table in how long you have to claim, the SLA glossary, or the live reliability rankings.

*Ontracko monitors 144 SaaS & cloud vendors' public status feeds, does this calculation automatically the moment a vendor breaches, and assembles the claim before the deadline. Monitor your vendors free — 8% only on recovered credits. See the live reliability rankings or pick your vendor's SLA page to estimate a credit.*