What uptime percentages mean
99.9% sounds like a promise of near-perfection. It is forty-three minutes of permitted downtime a month. Here is the arithmetic, and the much more important question of what is being measured.
The short version
- Each additional nine costs roughly ten times more and buys a tenth of the downtime.
- 99.9% is 43 minutes a month. 99.99% is 4 minutes. The gap is enormous in engineering terms.
- The measurement definition matters more than the number, and it is usually the vendor's.
- A composite system is less available than its least available component.
Uptime is quoted as a percentage because a percentage sounds precise. It is worth converting to time immediately, because the intuition a percentage gives you is wrong.
The table
| Uptime | Per day | Per month | Per year |
|---|---|---|---|
| 99% | 14m 24s | 7h 18m | 3d 15h |
| 99.5% | 7m 12s | 3h 39m | 1d 19h |
| 99.9% | 1m 26s | 43m 28s | 8h 46m |
| 99.95% | 43s | 21m 44s | 4h 23m |
| 99.99% | 8.6s | 4m 21s | 52m 36s |
| 99.999% | 0.86s | 26s | 5m 15s |
Two things jump out. 99% - Which sounds respectable - Is more than three and a half days a year, which for anything people depend on is dreadful. And the difference between 99.9% and 99.99% is the difference between a bad afternoon and a coffee break.
Why each nine costs ten times more
Because each one removes a different class of problem, and the classes get progressively harder.
Reaching 99% requires basic competence: A server that restarts when it crashes, backups, someone who notices.
Reaching 99.9% requires redundancy. No single machine can fail and take the service with it. Deploys must not cause downtime. Someone must be on call.
Reaching 99.99% requires surviving the failure of a whole zone or region, which means multi-region data replication and automated failover - And that is the point at which the hard distributed systems problems begin. Four minutes a month is less than most human response times, so recovery must be automatic.
Reaching 99.999% means twenty-six seconds a month. No human is in the loop. Every deploy is progressive with automatic rollback, every dependency has a fallback, and the organisation practises failure deliberately. Very few services genuinely achieve this, and many that claim it are measuring something narrow.
The measurement is the whole game
The percentage is arithmetic. The definition is where the real content is, and it is almost always written by the vendor.
What counts as down? Completely unreachable, or degraded? A service where every request takes thirty seconds is unusable and may count as up.
Measured from where? Inside the provider's own network, or from where users are? Internal monitoring cannot see a problem at the edge.
Averaged over what? Per region or globally? A total outage in one region out of twenty barely moves a global average, while being a total outage for everyone in that region.
What is excluded? Scheduled maintenance is excluded from essentially every commercial SLA. So is anything attributed to a third party, to force majeure, or to the customer's own configuration.
The consequence: A provider can honestly report 99.99% availability during a month in which you experienced hours of unusable service. Both statements are true; they are measuring different things.
Composite availability
The arithmetic that catches people out. If your application depends on several services in series, and it needs all of them, the availabilities multiply.
Five dependencies at 99.9% each gives 99.9%5 ≈ 99.5% - About three and a half hours a month, from five components that each individually promise forty-three minutes.
This is why "we use providers with 99.99% SLAs" does not mean your service is 99.99% available. Every dependency you add lowers the ceiling, and the ceiling is the product of all of them.
Redundancy works the other way. Two independent components in parallel, either sufficient, gives a failure probability that is the product of their failure probabilities - Two 99% components in parallel are 99.99% together, provided they are genuinely independent. That proviso does most of the work: Two servers in the same rack on the same power feed are not independent.
What our numbers mean
For transparency about this site specifically, since the argument above applies to us as well.
The uptime percentage on each status page is observed availability from one vantage point at 20-minute resolution. It is the proportion of measured time in which our probe could reach the service and get a usable response, computed from recorded downtime rather than from the ratio of passed to failed checks.
It will usually read higher than the true figure, because a single probe of a home page every 20 minutes cannot see regional outages, mobile app failures, feature-level breakage or anything shorter than the check interval. It is a floor on how bad things were, not a ceiling. The full methodology is explicit about the limitations, and it should be - A number presented without its definition is not a measurement.
What to do with a number
When someone quotes an uptime figure, three questions: Over what period, measured how, and excluding what. If any is unanswerable, the number is marketing.
And be wary of very short windows. "100% uptime this month" is true of a great many services in any given month and says nothing about the year.
Questions people ask
How much downtime is 99.9% uptime?
About 43 minutes a month, or 8 hours 46 minutes a year. It sounds close to perfect and is enough for a substantial outage every month - Which is why serious services quote 99.95% or 99.99% instead.
What is the difference between 99.9% and 99.99% uptime?
Roughly 39 minutes a month - 43 minutes versus 4. In engineering terms the gap is enormous: 4 minutes a month is shorter than most human response times, so recovery has to be fully automatic rather than someone being paged.
Why does a provider report high uptime when I experienced an outage?
Because of how it is measured. Scheduled maintenance is normally excluded, measurement is often from inside the provider's own network, and a regional outage barely moves a global average. Both statements can be true because they measure different things.
How do I calculate the uptime of a system with several dependencies?
Multiply them. Five services at 99.9% each, all required, gives 99.9% to the fifth power, which is about 99.5% - Roughly three and a half hours a month. Every dependency you add lowers the ceiling.
Read next
Service level agreements explained
What service level agreements really commit a provider to, how credits are calculated and claimed, and the exclusions that matter most.
Incident metrics that matter
What MTTR, MTBF, MTTD and MTTA actually measure, why means are misleading for incident data, and which metrics change behaviour.
How status pages work
Why official status pages lag user reports, how they are built, and how to read one properly - Including what a green banner does not mean.
Monitoring your own site
How to set up uptime monitoring that actually catches problems: What to check, from where, how often, and what to alert on.