Cloud providers publish generous-looking SLAs because they know a simple truth: credits only cost them money when customers file claims, and almost nobody files. The process is deliberately manual - evidence, deadlines, support cases - and the money quietly expires. This guide is the complete, provider-by-provider process for getting it back.
Step 1: Confirm the breach is claimable
An SLA claim starts with one number: the service's monthly uptime percentage. Take the total minutes the service was unavailable to you in the billing month, and convert:
uptime % = (43,200 − downtime minutes) ÷ 43,200 × 100
Compare the result against the service's SLA target - not a generic "99.9%" but the specific commitment for your configuration. Azure VMs illustrate why configuration matters: zone-redundant deployments carry a 99.99% target, availability sets 99.95%, and a single premium-SSD instance only 99.9%. The same 40-minute outage can be a breach in one configuration and inside the SLA in another.
If the measured uptime is under the target, use the calculator to see the tier and dollar figure - then keep going, because the money does not arrive on its own.
Step 2: Gather evidence immediately
Evidence gets weaker every day after an incident. Provider health dashboards show limited history, and your own metrics may be downsampled after weeks. Capture, at minimum:
- The provider's own record - AWS Health Dashboard events, Azure Service Health incident IDs, Google Cloud status page entries. Screenshot and export; these are the least disputable artifacts.
- Your monitoring - availability graphs, synthetic checks, error-rate dashboards covering the incident window, with timestamps and time zones visible.
- Affected resource identifiers - instance IDs, bucket names, database identifiers, project/subscription IDs. Claims are evaluated per resource, per region.
- Error samples - a handful of failed request IDs or 5xx logs. AWS explicitly asks for request logs that corroborate the outage.
A useful habit: open the claim folder the same day the incident resolves, while the evidence is one click away.
Step 3: Know your deadline
Each provider runs a different clock, and missing it forfeits the credit:
| Provider | Claim channel | Deadline |
|---|---|---|
| AWS | Support Center case ("SLA Credit Request" in the subject) | End of the second billing cycle after the incident (~60 days) |
| Azure | Azure support request, or licensing channel for EA | Within two months of the end of the billing month |
| Google Cloud | Technical support notification | Within 30 days of the incident |
Google's 30-day window is the one that catches teams out - a post-incident review that slips a sprint can eat most of the claim period.
Step 4: File the claim
Write the claim like an invoice, not a complaint. The reviewer needs to verify four things - make each one impossible to miss:
- Which SLA - name the document ("Amazon Compute Service Level Agreement").
- Which month and resources - billing month, account/subscription/project, affected resource IDs and regions.
- The measured uptime and tier - "measured uptime of 99.78% falls below the 99.99% commitment, in the ≥99.0% tier."
- The requested credit - "10% of the month's EC2 charges in us-east-1: $1,240."
Attach the evidence from Step 2. Keep the tone factual; the SLA makes this a contractual entitlement, not a favor.
Step 5: Track the outcome
Approved credits appear on a subsequent invoice - typically one to two billing cycles later - as a line-item credit against the affected service. Verify it lands; a surprising number of approved claims die between approval and invoicing. If a claim is rejected on exclusions (maintenance windows, customer-caused downtime), ask for the specific exclusion clause and re-check it against your evidence - exclusion calls are frequently reversible with better data.
The mistakes that get claims denied
- Claiming the whole bill. Credits apply to the affected service's charges, not the account total. Overclaiming triggers slow, skeptical review.
- Blowing the window. The single most common failure. Set the claim reminder the day the incident resolves.
- No resource-level detail. "Us-east-1 was down" is not evidence your resources were. IDs and logs make it your outage.
- Confusing region and zone failures. Most compute SLAs measure region-level availability; a single-AZ event may not breach the regional SLA even though it hurt you.
- Forgetting configuration prerequisites. Some SLAs require a specific architecture (multi-AZ, multiple instances) to hit the highest target. Know which target you're claiming against.
What this is worth
The arithmetic favors claiming. On a $50,000/month service, the tiers pay $5,000 (10%), $12,500 (25%), and up on a single bad month. Even the modest breaches - an hour or two of regional trouble - routinely clear four figures for the time it takes to write one support case. The providers' bet is that you won't. Take the other side of that bet.