Why Most SLA Credits Go Unclaimed

Every major cloud SLA promises tiered credits - 10%, 25%, even 100% of your monthly bill. On paper, the December-2021-class outages should have produced a flood of payouts. They didn't, and the reasons are structural, not accidental.

Claims are manual by design

None of the big three pays automatically. AWS wants a support case with "SLA Credit Request" in the subject; Azure wants a support request per subscription; Google wants notice within 30 days. Each step is small; together they form a filter that most busy teams never pass through. The provider's actuarial bet is simple: published generosity, claimed rarely.

Nobody owns the claim

Engineering feels the outage; finance sees the invoice; neither owns "file the claim." By the time the numbers meet - if they ever do - the window has usually closed. The fix costs one sentence in a runbook: the incident isn't closed until the SLA check is done. Our playbooks give that sentence a checklist to point at.

The evidence decays faster than the deadline

The claim needs measured uptime, resource IDs, and provider health-history references. All of it is easy to capture the day the incident resolves and painful to reconstruct five weeks later when someone finally asks "couldn't we get money back for that?" Deadlines are 30–60 days; memories are shorter.

The money is invisible

An unclaimed credit never appears as a loss anywhere. No budget line reads "SLA credits forfeited: $18,400." Costs that are invisible don't get managed - which is why teams that start measuring recoverable credits (start with the estimate) almost always start claiming them.

The fix is a routine, not a heroic effort

Detection you don't run yourself (outage alerts), a claim owner named in the incident template, the email templates pre-filled, and a quarterly reconciliation pass. Or automate the loop end-to-end - the point is that "we should claim that" becomes a process instead of a regret.