A cloud SLA looks like a simple promise: 99.99% uptime, credits if we miss. The headline number is the easy part. The money hides in the fine print, where exclusions, configuration prerequisites, and definitions of "unavailable" decide whether your outage counts at all. Read those sections wrong and you file a claim that was never eligible.
This guide walks through the clauses that matter, in the order they trip people up. When you are ready to turn a covered outage into a dollar figure, our SLA calculator does the tier math for you.
Start with the definition of "unavailable"
Before anything else, find how the SLA defines downtime. This one definition governs the entire claim. Providers do not measure "the service felt slow." They measure a specific failure condition, often:
- Error rate: the percentage of requests returning server errors over a rolling window.
- Connectivity: total loss of external connectivity to your resources.
- A per-resource condition: availability measured against each instance or endpoint, not the service as a whole.
If your incident was elevated latency but not outright errors, many SLAs will not count it. Match your evidence to the provider's definition, not your own experience of the outage. Our evidence guide covers capturing proof that fits the definition.
Region versus zone: the trap that voids claims
This distinction quietly kills more claims than any other. An SLA may measure availability at the region level, the availability zone level, or per resource, and each provider does it differently.
- A single-zone failure may not breach a region-level SLA at all, because the region as a whole stayed "available."
- Some SLAs only pay out if you were running across multiple zones and still went down. If you deployed to one zone, you may have voided the coverage yourself.
Read the availability definition and ask: at what scope is uptime measured, and did my architecture meet the precondition? If the SLA rewards multi-zone deployment, a single-zone footprint is a self-inflicted exclusion.
Configuration prerequisites you must meet first
Many SLAs are conditional. The credit only applies if you configured the service a specific way. Common prerequisites:
- Running a minimum number of instances or across a minimum number of zones.
- Using a supported instance or resource class (SLAs frequently exclude preview, beta, or free-tier resources).
- Following the provider's documented deployment or redundancy pattern.
If you did not meet the prerequisite, the outage still happened, but the SLA does not cover it. Check these before you count on a credit, not after you file.
The exclusions list is where breaches disappear
Every SLA has an exclusions section, and it is written to be broad. Downtime typically does not count if it was caused by:
| Excluded cause | What it means for you |
|---|---|
| Factors outside the provider's reasonable control | Force majeure, internet backbone failures |
| Your own actions or code | Misconfiguration, quota limits you hit, bad deploys |
| Beta, preview, or free-tier services | No SLA coverage at all |
| Scheduled or announced maintenance | Planned windows are usually carved out |
| Third-party equipment or software you introduced | Anything not fully managed by the provider |
The practical move: before filing, read the exclusions and honestly rule out each one for your incident. If the root cause was a provider-side region event on a supported, correctly configured service, you are on solid ground. If the cause was your own quota or a beta feature, the claim is dead on arrival. Our claim-mistakes breakdown covers how these exclusions get claims denied.
Find the tier table and the claim window
Two more sections decide the outcome. The tier table maps measured uptime bands to credit percentages, and it varies by service, so use the table for the exact service that broke. The claim window is the deadline: roughly 60 days for AWS and Azure, 30 days for Google Cloud. Both live in the same document as the exclusions.
Our primer on how cloud SLAs work explains what the "nines" translate to in real downtime minutes, which is the input for the tier table.
A reading checklist for any cloud SLA
Work through the document in this order and you will not miss the load-bearing clauses:
- Definition of unavailable: what failure condition is actually measured.
- Measurement scope: region, zone, or per resource, and any multi-zone precondition.
- Configuration prerequisites: what you had to run to be covered.
- Exclusions: the causes that void the breach.
- Tier table: uptime bands to credit percentages for that specific service.
- Claim window: the hard deadline to file.
Read once, claim with confidence
The fine print is not there to stop you claiming. It is there to define exactly what counts, and once you know the definition, scope, prerequisites, and exclusions, an eligible breach is straightforward to prove. Confirm the outage fits every clause, then follow our filing guide and how-it-works overview.
If parsing SLA documents across multiple providers sounds like a job in itself, that is what tooling is for. Cloud Credits handles the billing-accuracy side, live outage data is at Cloud Downtime, and Next Signal (our sponsor) reads the terms, watches your accounts, and drafts the claim automatically. When you have a covered breach, check the credit math and file.
