A vendor proudly advertises 99.9% uptime. It sounds like a rounding error away from perfect — surely that's basically never down? Then their service goes dark for 40 minutes one month, and… they're still within their promise.
The nines are sneaky. A number that sounds like perfection can hide hours of downtime a year. Let's translate those percentages into real, human time — so you know what you're promising, and what you're being promised.
What "uptime %" actually measures
Uptime is simply the share of time your service was available over a period:
Uptime % = (total time − downtime) ÷ total time × 100
So 99.9% uptime over a 30-day month means you were down for 0.1% of that month. The whole game is figuring out what that little percentage works out to in minutes — and it's almost always more than people expect.
The nines, in real time
Here's the table worth bookmarking. Each extra nine is roughly ten times harder to reach:
| Uptime | Downtime / day | Downtime / month | Downtime / year |
|---|---|---|---|
| 99% ("two nines") | ~14m 24s | ~7h 18m | ~3.65 days |
| 99.5% | ~7m 12s | ~3h 39m | ~1.83 days |
| 99.9% ("three nines") | ~1m 26s | ~43m 50s | ~8h 46m |
| 99.95% | ~43s | ~21m 54s | ~4h 23m |
| 99.99% ("four nines") | ~8.6s | ~4m 23s | ~52m 36s |
| 99.999% ("five nines") | ~0.9s | ~26s | ~5m 15s |
Read that 99% row again: "ninety-nine percent uptime" allows more than seven hours of downtime a month. It sounds great and is, frankly, not great at all.
How it's calculated
The maths is simple once you have the period in minutes:
- A 30-day month = 43,200 minutes.
- 99.9% uptime → allowed downtime = 0.1% × 43,200 = 43.2 minutes.
- A 365-day year = 525,600 minutes.
- 99.9% → 0.1% × 525,600 = 525.6 minutes ≈ 8h 46m.
You can run these numbers for any target — or skip the arithmetic and use our free uptime / downtime calculator to turn any percentage into real allowed downtime instantly.
Why "100%" is the wrong goal
It's tempting to aim for the top. Don't. Two reasons:
- It's effectively impossible. Deploys, certificate renewals, cloud-provider blips, DNS changes — something will eventually cost you a few seconds. Promising 100% just means promising to fail.
- The last fraction costs the most. Going from 99.9% to 99.999% can mean a fortune in redundancy and engineering for a few minutes of saved downtime a year. For most services, that money is better spent elsewhere.
The right target isn't "as high as possible" — it's "as high as your users genuinely need, and no higher." A marketing site and a payments API have very different needs, and very different price tags.
How to pick a target
- Start from the user. What downtime would they actually notice and care about?
- Look at what you already deliver. Pull a few months of real data; don't promise five nines if you're naturally at three.
- Leave yourself a margin. If you promise customers a number (an SLA), aim internally for something stricter, so a bad week doesn't breach the contract.
- Measure it honestly. Your uptime number is only as good as the monitoring behind it — checked frequently, from multiple places, confirmed before counting as downtime.
The bottom line
| Target | Allowed downtime / month | Feels like |
|---|---|---|
| 99% | ~7h 18m | "We're down a few times a month" |
| 99.9% | ~44m | Solid for most products |
| 99.99% | ~4m | Serious, expensive |
| 99.999% | ~26s | Rarefied air |
"99.9%" isn't a magic number — it's about 44 minutes a month. Once you can translate the nines into real time, you'll never be dazzled (or fooled) by an uptime promise again.
Crunch your own numbers with the uptime calculator, and dig into how targets become commitments in SLA vs SLO vs SLI.