Where claims go, per provider
None of the big three has a "claim SLA credit" button. Claims travel through the support and billing machinery, and each provider has its own route and deadline:
| Provider | Route | Window | Credit applies as |
|---|---|---|---|
| AWS | Support case ("Account and billing" → SLA credit request) | ~60 days | Credit against future bills |
| Azure | Support request against the affected subscription | ~60 days | Credit on a subsequent invoice |
| Google Cloud | Support / billing request for the affected project | ~30 days | Credit to future use |
Anatomy of a claim that gets approved
Reviewers process volume. A claim that does their work for them, states the breach, shows the math, attaches the proof, gets approved faster and disputed less. The structure:
State the assertion in one sentence
"Service X in region Y fell below its committed Monthly Uptime Percentage of 99.99% for the month of June 2026, qualifying for a 10% service credit."
Give the incident window in UTC
First failure to last failure, with the measurement source named. Precision here signals the rest of the claim is precise too.
Show the uptime math
Downtime minutes over the month's total minutes, the resulting percentage, the committed percentage, and the matched credit tier. Four numbers, no rhetoric.
Attach the evidence file
Request IDs, error samples, exported graphs, resource IDs, and any provider acknowledgments, assembled as described in part 5.
Name the amount
The affected service's monthly charge from the invoice, the tier percentage, and the resulting credit figure. Make the payout a fill-in-the-blank, not a research project.
Why claims get rejected
- Filed outside the window. The most common and least appealable rejection. The countdown starts at the incident, not at your discovery of it.
- Wrong scope. The claim names a service or region the SLA measures differently, or lumps several services into one claim when each needs its own.
- Architecture didn't qualify. Single-AZ deployments claiming the multi-AZ SLA tier. The reviewer checks; see part 3.
- Insufficient evidence. "The status page showed an incident" without your own timestamps and request-level proof of impact on your resources.
- Excluded cause. The provider attributes the downtime to customer configuration, maintenance, or an excluded dependency, and nothing in the claim rebuts it.
The follow-through
Approval is not the finish line; the invoice is. Track three things: the support case until it resolves, the approved amount against what actually lands, and the invoice line where the credit appears, remembering that credits offset future charges, so the money surfaces a cycle later. If the approved credit never materializes, reopen the case with the case number and approval text. It happens more than it should.
Make it a monthly close step
Run the whole loop, uptime check, evidence review, filings, credit reconciliation, as part of month-end close. One recurring calendar block turns credit recovery from a heroic one-off into a line item that reliably pays for the meeting. Teams that want the loop automated end to end, detection through documentation, use platforms like Next Signal; teams that run it manually just need the discipline.
Key takeaways
- Claims route through support and billing machinery: AWS and Azure allow ~60 days, GCP ~30.
- A strong claim is assertion, UTC window, uptime math, evidence, and amount, in that order.
- Rejections cluster on five causes: late, mis-scoped, unqualified architecture, thin evidence, excluded cause.
- Credits pay against future invoices. Verify the credit lands; reopen the case if it doesn't.
- Run the loop at month-end close. Recovery is a process, not an event.