Every cloud contract expresses reliability the same way: as a percentage with some number of nines. The notation is compact, which is exactly the problem. Percentages hide the only unit that matters to your business, which is minutes of downtime you have agreed to absorb.
Each nine is a 10× cut, not an increment
Moving from 99.9% to 99.99% does not improve reliability by 0.09 percentage points in any meaningful sense. It divides the allowed downtime by ten. Three nines permits 8 hours 46 minutes of downtime a year. Four nines permits 52 minutes 34 seconds. Five nines permits 5 minutes 15 seconds, less time than it takes most teams to acknowledge a page.
Because SLA credits are calculated monthly, the monthly framing matters more in practice: three nines allows about 43 minutes a month, while four nines allows about 4 minutes 19 seconds. A single 30-minute incident is comfortably inside a 99.9% SLA and catastrophically outside a 99.99% one. Same outage, completely different contractual meaning.
Where cloud SLAs actually sit
Marketing pages love "five nines." Contracts mostly do not. The flagship compute SLAs at AWS, Azure, and Google Cloud commit to 99.99% monthly uptime for properly architected deployments, and many managed services commit to 99.9%. Five nines, as No Jitter's analysis puts it, is largely aspiration: real-world incidents burn through a five-nines budget in a single event.
The same analysis offers two useful case studies. Two short power incidents at a Rackspace facility in 2009, about an hour of combined downtime, pulled annual availability down to 99.98%. The April 2011 AWS EC2 outage took roughly three hours to contain and spilled into the next day, dragging availability to about 99.5% for affected customers. One bad day can consume years of nines.
| Availability | Per year | Per month | Per week |
|---|---|---|---|
| 99.9% | 8h 46m | 43m 12s | 10m 5s |
| 99.99% | 52m 34s | 4m 19s | 1m 1s |
| 99.999% | 5m 15s | 26s | 6s |
| 99.9999% | 32s | 2.6s | 0.6s |
Why providers price the gap
Each additional nine costs the provider exponentially more to engineer: redundant power and network paths, multi-zone replication, automated failover that itself must not fail. That is why the highest commitments come with architectural strings attached. AWS's 99.99% compute SLA, for example, applies to instances deployed across multiple Availability Zones. Run everything in one zone and you may be measured against a lower bar, or none.
This is worth internalizing before you ever file a claim: the nines you are owed depend on how you deployed, not just on what the provider brochure said.
What this means for credits
The SLA percentage is not just a quality promise. It is the tripwire for compensation. When measured monthly uptime falls below the committed figure, the provider owes you service credits on a published schedule, typically starting at 10% of the affected service's monthly charge and rising to 100% for severe misses. If you do not know which nines apply to each of your services, you cannot know when you have crossed the tripwire, and every breach passes silently.
The next article in this series puts a dollar figure on those minutes. Because 52 minutes sounds small until you price it.
Key takeaways
- Each added nine cuts allowed downtime by 10×. Three nines is 8h 46m a year; four nines is 52 minutes.
- Credits are assessed monthly: 43 minutes of slack at 99.9% vs about 4 minutes at 99.99%.
- Most cloud SLAs commit to between three and four nines. Five nines is mostly marketing.
- The committed percentage is the tripwire for service credits. Know yours per service.
- Architecture prerequisites (like multi-AZ) decide which SLA you are measured against.