The Field Guide  /  Part 4 of 7

Why credits go unclaimed

The money leaks for boring reasons: nobody is watching the right number, nobody owns the claim, and the window closes while the invoice is still unopened. Every step is fixable.

6 min readUpdated July 2026Downtime, decoded

The default outcome is zero

Everything in the previous article points one direction: the provider owes you nothing until you ask. There is no invoice line that says "SLA breach detected, credit applied." The system's default state is that breaches produce no payout, and every organizational failure below simply preserves that default.

Where breaches fall out of the funnel
Illustrative shares, based on the failure patterns we see repeatedly. The exact numbers vary by team; the shape does not.
Breaches that occur100%
Noticed at allindependent monitoring exists~55%
Recognized as SLA-relevantsomeone knows the threshold~25%
Documented in timeevidence captured~12%
Filed inside the window~5%
Illustrative funnel. The structural causes at each stage are documented below.

Failure one: nobody is measuring uptime against the SLA

Teams monitor what pages them: latency, error budgets, customer complaints. Almost nobody runs a monthly job that asks "did measured availability for each paid service fall below its committed percentage?" Without that comparison, a 99.95% month against a 99.99% commitment, a clear 10%-credit breach, looks like a normal month. The outage was survived, the retro was written, and the contractual fact of it was never computed.

Failure two: the ownership gap

Ask who owns SLA claims in most companies and you get a pause. Infrastructure saw the outage but does not read invoices. Finance reads invoices but never saw the outage. FinOps, where it exists, is busy with rightsizing and commitments. The claim needs someone who can hold both the incident timeline and the billing data, and in most org charts that intersection is empty.

A claim requires the outage data and the billing data in the same pair of hands, inside 60 days. Most companies have no such pair of hands.

Failure three: the window

Claim windows are short by design: roughly 60 days for AWS and Azure, 30 for Google Cloud. Compare that to how incidents actually surface in finance: the invoice arrives after month close, gets reviewed days or weeks later, and a spend anomaly gets questioned in the next monthly review. By the time a March outage becomes a June conversation, the AWS window has closed and the GCP window has been shut for two months.

The claim window against a typical finance calendar
Day 0 is the incident. The window closes long before most finance workflows would surface the question.
Day 0outage ~Day 15invoice lands Day 30GCP closes Day 60AWS & Azure close
first realistic finance touchpoint too late
Windows per provider agreements; see the provider playbooks for specifics.

Failure four: the effort myth

"Not worth the paperwork" is the last line of defense, and it is usually wrong twice. It overestimates the work: with evidence already organized, a claim is an afternoon, not a project. And it underestimates the payout: 10% of a $80,000 monthly service charge is $8,000, per breach, and Splunk's research puts the average organization at 60 disruptions a year. The paperwork objection is how five-figure annual recovery becomes zero.

Closing the gap

The fixes map one-to-one to the failures:

Key takeaways

  • The default outcome of every SLA breach is zero payout. Claims are always customer-initiated.
  • Breaches leak at four stages: unnoticed, unrecognized, undocumented, unfiled.
  • The ownership gap is structural: claims need incident data and billing data together, and no one holds both.
  • Claim windows (30 to 60 days) close faster than normal finance workflows surface the question.
  • Each fix is cheap: monthly SLA checks, a named owner, a calendared countdown, immediate evidence capture.

How much has already leaked?

Run last month's downtime through the calculator and see what went unclaimed.