The unit of account: Monthly Uptime Percentage
Cloud SLAs are settled monthly, per service, per account. The core metric is the Monthly Uptime Percentage: the share of minutes in the billing month during which the service met the provider's definition of "available." When that percentage lands below the committed figure, a credit tier applies to that month's charges for the affected service.
Two consequences follow. First, an outage's contractual weight depends on which month it lands in, since the clock resets on the first. Second, the provider's definition of "unavailable" is narrower than yours: it usually means their error rates or connectivity failures, measured their way, not "our app was slow."
| Monthly uptime | AWS | Azure | Google Cloud |
|---|---|---|---|
| 99.0% – < 99.99% | 10% | 10% | 10% |
| 95.0% – < 99.0% | 30% | 25% | 25% |
| Below 95.0% | 100% | 100% | 100% |
Scope: the SLA you get depends on how you deployed
The highest commitments carry architectural prerequisites. AWS's 99.99% compute commitment applies to instances running across multiple Availability Zones; a single-instance deployment is measured against a lower instance-level SLA. Azure and Google structure theirs similarly: the marquee number assumes you built the way the provider recommends. Before assuming a breach, confirm which tier of the SLA your architecture actually qualifies for, because the provider's claims reviewer certainly will.
The exclusions: where claims go to die
Generally counts toward a breach
- Provider-side connectivity loss in a covered region
- Elevated internal error rates the provider acknowledges
- Failures of the provider's own infrastructure or dependencies
- Downtime measured within the monthly window, per service
Excluded from the math
- Your own misconfiguration, code, or third-party software
- Deployments that don't meet SLA prerequisites (e.g. single-AZ)
- Scheduled or announced maintenance windows
- Preview, beta, and free-tier services
- Force majeure and factors outside the provider's control
Most rejected claims fail on this page of the agreement, not on the uptime math. If the outage traces to something in the left column and your evidence shows it, you have a claim. If the provider can plausibly file it in the right column, you have a learning experience.
The cap and the currency
Two limits govern every payout. First, credits are capped at 100% of the monthly charge for the affected service, no matter how bad the month was. Second, you are paid in credits, not cash: as No Jitter notes of the AWS agreement, credits apply against future bills. And no provider SLA covers consequential damage. The agreement language is explicit that lost business, lost data value, and legal exposure are yours to carry. The SLA is a service-price rebate mechanism, not insurance.
And none of it happens automatically
The most important sentence in every cloud SLA is the one requiring you to submit the claim, with evidence, inside a window of 30 to 60 days. The provider does not proactively issue credits for most services, however visible the outage was. Why teams fail at precisely this step is the subject of the next article.
Key takeaways
- SLAs settle monthly, per service: the Monthly Uptime Percentage decides everything.
- Credit tiers start around 10% and reach 100% of the affected service's monthly charge.
- Architectural prerequisites (multi-AZ and similar) decide which SLA tier you can invoke.
- Exclusions, not math, kill most claims: misconfigs, maintenance, and non-qualifying deployments don't count.
- Credits are capped, paid against future bills, and never cover business losses. And they must be claimed.