What an SLA credit is actually worth.

When a vendor breaks its uptime promise, it owes you money. Not metaphorically — contractually. AWS, like most infrastructure vendors, publishes a service level agreement with exact credit tiers: miss the target by this much, get this percentage of the month's charges back.

Most teams never collect. Not because the amounts are trivial, but because the burden of proof sits entirely on the customer, and by the time anyone thinks to file, the evidence is gone or the deadline has passed.

This post walks through what a credit is actually worth, using AWS's published tiers — the same terms our AWS claim guides render and our credit computation enforces. No estimates, no modeling. Just the vendor's own numbers and some arithmetic you can check.

The published ladder.

AWS's EC2 SLA commits to 99.99% monthly uptime for instances deployed across multiple Availability Zones. When measured uptime falls below the target, the credit steps up as the breach gets deeper — the deepest breached threshold wins:

• Below 99.99% (but at least 99.0%) → 10% of monthly EC2 charges
• Below 99.0% (but at least 95.0%) → 30% of monthly EC2 charges
• Below 95.0% → 100% of monthly EC2 charges

That's the whole ladder, straight from AWS's EC2 SLA (opens in new tab). Other AWS products publish their own targets and ladders:

• S3 Standard commits to 99.9%, with tiers of 10% (below 99.9%), 25% (below 99.0%), and 100% (below 95.0%).
• Lambda and RDS Multi-AZ commit to 99.95%, with tiers of 10%, 30%, and 100% at the same breakpoints as EC2's lower two.
• DynamoDB Standard commits to 99.99%; DynamoDB Global Tables commits to 99.999% — five nines — with 10% below that, 25% below 99.9%, and 100% below 99.0%.
• CloudFront and Bedrock commit to 99.9%.

Two things to notice. First, the targets differ per product — "AWS was down" is not a claim; "EC2 in this region fell below 99.99% this month" is. Second, the credit applies to the affected product's monthly charges, not your whole AWS bill. A breach on Lambda pays out against what you spent on Lambda.

A worked example.

Say you spend $4,000 a month on EC2. That figure is an illustration — pick your own bill; the percentages are what's real.

A 30-day month has 43,200 minutes. The 99.99% target allows about 4 minutes 19 seconds of downtime before the SLA is breached.

Now suppose EC2 in your region has a bad afternoon: 3.5 hours — 210 minutes — where your multi-AZ instances have no external connectivity. Measured uptime for the month:

(43,200 − 210) ÷ 43,200 = 99.51%

That's below 99.99% but above 99.0%, so the first tier applies: 10% of the month's EC2 charges, or $400 on the hypothetical $4,000 bill.

The deeper tiers take real carnage to reach. Dropping below 99.0% requires more than 432 minutes of downtime in the month — over 7 hours — and pays $1,200. Dropping below 95.0% requires more than 36 hours down and pays the full $4,000.

Is $400 fair compensation for a 3.5-hour outage? Almost certainly not — your revenue loss and engineering time likely exceeded it. SLA credits are bounded by design; they're a rebate, not damages. But it's real money that the vendor's own contract says you're owed, it recurs every time the SLA is breached, and across a stack of vendors and a year of incidents it adds up. The only question is whether you can prove it.

What "down" means to AWS.

Here's the part that decides most claims. AWS doesn't measure downtime the way your incident channel does.

The standard AWS measurement works in five-minute slots: a slot counts as unavailable only when the service was down for the entire five minutes. A four-minute outage contributes zero. Sixty seconds of errors every five minutes all day contributes zero. Our own credit computation implements this rule exactly as written, because a claim that counts partial slots over-counts in AWS's eyes and gets denied.

The exclusions matter just as much:

• Single-AZ failures don't count against the Multi-AZ EC2 and RDS targets. If only one Availability Zone went dark and you were deployed across two, the SLA holds.
• Scheduled maintenance is excluded across the AWS terms we track.
• The window is a calendar month. An outage spanning midnight on the last day of the month splits across two measurement windows, each judged separately.

None of this is hidden — it's all in the published terms. But it means the number you need is not "how long was the incident" but "how many complete five-minute slots, in which calendar month, excluding maintenance and single-AZ scope." That's a number you can only produce if something was measuring at that granularity while the incident happened.

The mechanics that decide whether you see the money.

Three more facts from the same terms, each one a way to lose a valid claim:

The filing window is 60 days, counted from the end of the billing cycle in which the breach occurred. Miss the deadline and the credit is forfeit. AWS does not file on your behalf, and nothing in your bill will remind you.

The evidence burden is specific. AWS requires your account ID, the affected region, the affected resource ARNs, and documentation of the failure — the incident's status-page entry plus your own request logs. Lambda claims additionally want sampled request IDs from failed invocations. Claims without the required evidence are routinely denied.

The channel is a support case. You open a case in the AWS Support Center under the account and billing category, reference the incident window and the affected product, and state the credit tier you're claiming. The credit lands against a future bill; it isn't a cash refund.

Why credits mostly go unclaimed.

Put those mechanics together and the shape of the problem is clear.

To collect a $400 credit you need to know, within 60 days of the billing cycle, that measured uptime for a specific product in a specific region fell below a specific threshold — computed in complete five-minute slots, net of exclusions — and you need contemporaneous evidence: timestamps, request IDs, resource ARNs, and the vendor's own acknowledgment if one exists.

The vendor's status page won't hand you this. Status pages are optimistic by design — they under-report, acknowledge late, and resolve early, and an unacknowledged breach is still a breach you're entitled to claim, if you can prove it independently. Reconstructing five-minute granularity three weeks after an incident, from logs you weren't retaining for this purpose, is the point where most claims quietly die.

The math is trivial. The proof is the product.

Making the breach provable.

This is why we treat SLA terms and measurement as one system rather than two features. The terms above live in our AWS vendor pack as structured rules — target, ladder, window, exclusions, deadline, evidence list, filing channel. Our independent measurement runs against the same five-minute-slot definition the terms use. When a monthly window closes below target, the credit computation is a pure function over measured data and published terms: the same inputs always produce the same claim figure, and a finance team can re-derive every number in it.

If you run on AWS, the claim guide walks the full filing process — the per-product targets and tiers, the evidence checklist, and the deadline — rendered from the same rules described here. Read the ladder against your own bill. The tiers are public, the arithmetic is yours to check, and the 60-day clock only runs one way.