Echo Support / SRE • • 1,154 words • 6 min read
The 99.999% Uptime Myth: Why Cloud SLAs Won't Save You
Does five nines (99.999%) uptime really mean just 5 minutes of downtime a year? The hard truth about SLA credits, dependency chains and cloud outages.
TL;DR (Direct Answer): "Five nines" (99.999%) uptime means about 5 minutes of downtime a year, but that promise covers only one provider's piece of your system. Your app depends on a chain of services, and every link adds risk. When things break, SLA credits usually refund a small slice of your monthly bill, not the revenue you lost. Real reliability comes from your own design, monitoring, and backup plans.
The Bus That's "Never Late"
Imagine a bus company promising it's on time 99.9% of the time. It sounds perfect, until you're the one stranded in the rain. Cloud uptime promises work the same way. Here's what those decimals really mean per year:
| Promise | Nickname | Downtime per year |
|---|---|---|
| 99.9% | Three nines | ~8.7 hours |
| 99.99% | Four nines | ~52 minutes |
| 99.999% | Five nines | ~5 minutes |
Why should you care? Those hours land somewhere. They might hit the moment your banking app refuses a transfer or your checkout page hangs mid-order. One bad hour on a busy shopping day can cost more than a year of hosting.
How Uptime Promises Actually Work
SLA, SLO, SLI in Plain English
Think of a restaurant. The SLI (Service Level Indicator) is the actual measurement, like "how many minutes until food arrives." The SLO (Service Level Objective) is the internal goal: "under 15 minutes." The SLA (Service Level Agreement) is the written promise with a penalty: "late food, free dessert."
Who's Holding the Stopwatch?
Uptime depends on who measures it, from where, and over what window. Usually the provider measures it themselves. Fine print often excludes "planned maintenance" and "partial outages," so a service can be broken for you and still count as "up."
The Error Budget
Smart teams flip the idea around. If you target 99.9%, you have 8.7 hours a year you're allowed to fail. That's your error budget. Spend it on risky launches, and freeze changes once it runs low.
Single Region, Multi-Region, or Multi-Cloud?
A region is a cluster of data centers in one geographic area. Your options:
| Setup | Upside | Downside |
|---|---|---|
| Single region | Cheap, simple | One regional failure takes you down |
| Multi-region | Survives regional outages | Higher cost, tricky data syncing |
| Multi-cloud | No single vendor dependency | Most complex, double the expertise |
The Chain Math
Services in a row multiply their weaknesses. Five services at 99.99% each give you 0.9999⁵ ≈ 99.95%, roughly four and a half hours of downtime a year instead of 52 minutes.
Running backups side by side, called parallel redundancy, helps. Two independent 99.9% copies reach about 99.9999%, because both must fail at once. The catch is that you pay twice and manage twice the moving parts.
A Real Chain, Calculated
Here's a typical request path:
User → DNS → CDN → Load Balancer → App → Database
99.99% 99.99% 99.99% 99.95% 99.95%
Multiply them: 0.9999 × 0.9999 × 0.9999 × 0.9995 × 0.9995 ≈ 99.87%. That's about 11 hours of potential downtime a year, even though no single piece looks scary on paper.
The fix starts with seeing your site the way users do. Don't trust the dashboard. Check from outside:
curl -fsS -o /dev/null -w "%{http_code} %{time_total}s\n" https://example.com || echo "DOWN"
This prints your site's status code and response time, or "DOWN" if it fails. Schedule it from a different network. Want to see how failures spread through a system? Try our Interactive Engineering Simulations.
Myths, and the Day us-east-1 Blinked
Five Myths to Retire
- "The cloud never goes down." It does, regularly.
- "The SLA protects us." Credits are usually capped at 10–30% of the monthly bill and never cover lost revenue.
- "Status page is green, so we're fine." Status pages often lag reality.
- "Multi-cloud means resilient." Not if both clouds share a single DNS or login provider.
- "More nines are always better." Each extra nine costs dramatically more. Make sure your business needs it.
October 2025: The DNS Domino
On October 20, 2025, a race condition in automation managing DNS records for DynamoDB (AWS's database service) left a critical address empty in us-east-1. Apps couldn't find the database. Failures cascaded for hours across games, messaging apps, smart home devices, and payment services worldwide. Affected companies got bill credits. Their real losses in sales, support costs, and trust dwarfed them.
The cloud doesn't have to fail for you to fail, either. In July 2024, a faulty CrowdStrike security update crashed about 8.5 million Windows machines. Your own software supply chain is part of your uptime. Explore more failure stories in our AI Playground.
Frequently Asked Questions (FAQ)
Is 100% uptime possible?
No. Hardware fails, software has bugs, and humans make mistakes. Even the largest providers have outages every year. The realistic goal is to fail rarely, fail small, and recover fast. Aim for redundancy at critical points, clear runbooks, and good monitoring. Promising 100% usually means someone is measuring creatively, or simply hasn't been tested by a bad enough day yet.
How do I claim an SLA credit, and why do most companies skip it?
You usually file a support ticket within a deadline, often 30 to 60 days, with timestamps and evidence of impact. Many companies never bother. The payout is tiny compared with the effort, the burden of proof falls on you, and exclusions like "partial outage" often disqualify the claim. Teams frequently decide their engineering hours are better spent preventing the next outage.
How many nines does a small business need?
Most small businesses do fine with 99.9%, which allows about 8.7 hours of downtime a year. That works if outages avoid peak hours and customers get a clear message. Invest first in backups, an external uptime check, and a simple status page. Chasing four or five nines usually means multi-region setups whose cost and complexity outweigh the benefit at small scale.
Why are status pages updated so late?
Status pages are often updated by humans who must first confirm a problem, understand its scope, and get approval before posting. Some providers also hesitate to admit outages that might trigger SLA claims. Monitoring systems may themselves depend on the failing service. The result is that users on social media frequently notice problems well before the official page turns red.
How do I vet a provider's reliability promise before buying?
Read the SLA's exclusions, credit caps, and claim process carefully. Ask how availability is measured, from where, and over what time window. Review the provider's public incident history and post-mortems for transparency and recovery speed. Check which hidden dependencies, such as DNS or login services, you'd share with others. Finally, test failover yourself rather than trusting marketing pages or sales calls.