Why Most Companies Never Claim Cloud SLA Credits (and Who Actually Does)
August 10, 2026
On October 20, 2025, a race condition in AWS's internal DNS system deleted the IP addresses for the DynamoDB regional endpoint in us-east-1. The result was about 15 hours of disruption across an estimated 3,500 companies in more than 60 countries, and CRN put the total business loss at $581 million. Zoom, Capital One, Coinbase, DoorDash, and Reddit all went down. Here is the part that gets almost no coverage: nearly all of that money stayed lost. The SLAs those companies signed entitled most of them to service credits, and almost nobody filed.
That is not an anomaly. It is the default outcome of a system where the provider publishes the breach, the invoice never mentions it, and the customer has to ask within a window measured in weeks. Below: why credits go unclaimed, who actually collects, and what separates the two groups.
The credits are real, and they mostly go unclaimed
Every major provider has the same rule written into its SLA: the customer must ask. AWS's EC2 agreement says you receive a Service Credit "by opening a case in the AWS Support Center." Google's SLAs say the customer must notify technical support within 30 days of becoming eligible, and that failing to do so forfeits the right to the credit. DigitalOcean's Spaces SLA requires written notice within 24 hours of downtime starting, or the right is gone.
The scale is hard to take seriously until you see the numbers. Complaya, a startup that automates credit recovery, estimates global SaaS buyers miss out on more than $20 billion in unclaimed service credits. Next Signal's tracking of AWS status history counted 25 events in 2024 with more than 24 minutes of downtime, each one triggering SLA credit eligibility for affected customers. Nobody at AWS sends a note saying "you are owed 10% of last month." The breach is published, the money is owed, and the silence is the design.
The Uptime Institute said it plainly in 2022: users must measure the downtime and request the compensation themselves, because nothing is automatic, and the credit can only be redeemed with the provider that caused the outage. Their closing question was whether the benefit is worth the effort. Most teams answer with silence, which is itself an answer.
Why the payout looks like nothing
The first reason people skip claims is that the credit is small on purpose. It is a percentage of one month's bill for the affected service, not your lost revenue. The Uptime Institute ran the math: a t4g.nano in us-east-1 costs about $3 per month, so a breach that earns a 10% credit pays 30 cents. AWS and DigitalOcean do not even issue credits under $1.
That math flips hard as monthly spend on the affected service grows. The same 10% tier that pays 30 cents on a nano pays $500 on a $5,000 EC2 footprint, and the 30% tier is the one that shows up in quarterly reviews:
| Monthly spend on the affected service | 10% tier pays | 30% tier pays |
|---|---|---|
| $1,000 | $100 | $300 |
| $5,000 | $500 | $1,500 |
| $25,000 | $2,500 | $7,500 |
| $100,000 | $10,000 | $30,000 |
Keep the contrast in view: the Uptime Institute's 2021 survey found the average most significant downtime incident cost respondents $973,000, and 2% lost more than $40 million. A credit never covers the damage. The question is whether half an hour of filing beats the alternative, which is zero.
The clocks are short, and they start quietly
| Provider | Claim window | Channel | The catch |
|---|---|---|---|
| AWS | By the end of the second billing cycle after the incident, roughly 60 days | Support Center case with "SLA Credit Request" in the subject | Request logs from your own resources required; credits under $1 not paid |
| Azure | Within 2 months of the end of the billing month | Portal Help + support, issue type Billing, problem type Refund Request | CSP credits are filed only by providers, not indirect resellers |
| Google Cloud | Within 30 days of becoming eligible | SLA contact form | Miss it and the right is forfeited, no appeal |
| DigitalOcean | Within 30 days of the end of the billing cycle | Support ticket | Spaces requires written notice within 24 hours of downtime starting; App Platform allows to the end of the second billing cycle |
A breach on the first of the month can be dead before the invoice arrives. The clock starts when the incident ends, not when anyone is told, and the shortest window is Google's 30 days.
Every provider makes the customer the one who files, and every window is measured in weeks. A credit nobody claimed by the deadline is a credit that never existed. The breach is real, and the money is owed only to whoever asks in time.
The evidence is a second job
The third blocker is that filing is paperwork with a format. AWS wants the dates, times, region, resource IDs, and request logs that corroborate the outage on your resources. Microsoft's Partner Center guide for SLA credits asks for the customer tenant GUID, the outage incident ID from the Service Health Dashboard, proof the customer encountered the outage and requested the credit, and an email that comes from the affected tenant's domain, with personal addresses rejected. Google calculates credits per project and per product.
None of this is hard. It is exactly the work that does not get done inside a 30 to 60 day window while the team that lived through the incident is back to shipping. Evidence decays fast too: logs rotate, request data ages out, and reconstructing a timeline three weeks later is a job nobody volunteers for.
Who actually files
The people who collect are not the ones with the biggest losses. They are the parties with a recurring reason to care.
Managed service providers and IT providers file more than anyone else. They hold delegated access across dozens of accounts, so the volume makes the math work, and a recovered credit is a visible win the client can see on a bill. On Azure through the Cloud Solution Provider program the structure forces the point: Microsoft accepts SLA credit requests only from CSP direct and indirect providers, not from indirect resellers, and the approved credit lands on the provider's next invoice. The provider is the only party able to file, so providers who want the money learn the process.
Companies with large monthly spend file too, because the table above is their table: at $100,000 a month on a breached service, a 10% credit is a $10,000 line item, and a $10,000 line item finds an owner. And the third group is the small one that treats recovery as a scheduled task rather than an emergency response. The teams that collect do a billing-day review: first of the month, pull the previous month's incidents, match each to the services they run, and file anything still inside its window. It is a habit, not a hero moment.
What changes the math
Two things separate the filers from the silent majority. The first is detection that does not depend on reading the provider's status page after the fact; the AWS status page lagged the October 2025 event by hours, and every hour of lag is an hour of evidence you are not collecting. The second is a standing process with a deadline owner, so filing is a paste job instead of a reconstruction project.
Start with the last three months. Pull the incident history for the services you actually run, match each incident against the provider's monthly uptime commitment, and find the largest breach that is still inside its window. File that one end to end this week: evidence, subject line, deadline. If nothing is still in window, set a reminder for the first of next month and repeat the check. Tools like UptimeAudit watch the four providers down to service and region and draft the claim with the deadline attached, but the habit is the part that works even with a spreadsheet.