"We guarantee 99.9% uptime" sounds precise and reassuring. But ask a simpler question - how many minutes of downtime is that? - and most people guess wrong, usually by an order of magnitude. Percentages hide the arithmetic that matters. Let's do it properly.
The table everyone should have taped to a wall
Allowed downtime per availability level:
- 99% ("two nines") - 7 h 18 min per month, 3 days 15 h per year
- 99.9% ("three nines") - 43 min 49 s per month, 8 h 46 min per year
- 99.95% - 21 min 54 s per month, 4 h 23 min per year
- 99.99% ("four nines") - 4 min 23 s per month, 52 min 36 s per year
- 99.999% ("five nines") - 26 s per month, 5 min 15 s per year
Two observations fall out immediately.
First, 99% is not "almost perfect" - it's three and a half days a year of your site being dead. Nobody who says "we're up 99% of the time, that's fine" has translated it into days.
Second, the jump from three nines to four nines is brutal: you go from "an incident can last half an hour if handled well" to "an incident must be detected, diagnosed and fixed in under four minutes - or you've blown the month." That is no longer an ops habit; that's redundant infrastructure with automatic failover, because no human fixes anything in four minutes at 3 a.m.
The fine print that changes the number
The measurement window. "99.9% yearly" allows a single 8-hour outage - one bad Saturday and you're still compliant. "99.9% monthly" allows only 44 minutes at a time. Same number, very different promise. Monthly windows are stricter and are what most serious SLAs use.
Scheduled maintenance. Many SLAs exclude "planned maintenance windows" from the calculation. If maintenance is unbounded and self-declared, the guarantee is soft: a provider can be down for hours and count none of it. Read that clause first.
SLA versus SLO versus reality. An SLA (agreement) is a refund policy, not a physics constraint: if the provider misses it, you get service credits - usually a percentage of one month's fee. Your customers, meanwhile, experienced the outage in full. An SLO (objective) is what a team actually aims for internally. Reality is what a monitor measures. The three numbers are rarely equal, and only the third one is yours to verify.
*Availability of what? A homepage that renders while checkout is broken counts as "up" in most measurements and as "down" in every way that matters commercially. Decide which user journey defines "available" - for a shop it's completing a purchase, for a SaaS it's signing in and using the core feature - and measure that*.
Your monitor changes the number too
Uptime isn't observed directly; it's sampled. That has consequences.
Check interval sets your resolution. A monitor that checks every 5 minutes cannot see a 3-minute outage - or it sees a single failed check and can't tell you whether that was 10 seconds or 4 minutes of downtime. With 1-minute checks, a month has ~43,200 samples and your measurement error shrinks to the point where three-nines arithmetic is meaningful. This is why "free" 5-minute monitoring and a paid 60-second interval genuinely measure different things.
Retries decide false positives. A single failed request can be a routing blip between the monitor and your site. Good monitors retry after a short pause before declaring an incident; the cost is slightly delayed detection, the benefit is alerts you can trust. Without retries you either learn to ignore alerts (bad) or chase ghosts (worse).
One location lies a little. A check from a single network can be affected by that network's own issues, and can't see regional failures. Multiple vantage points solve this - but even a single external location is categorically better than checking from the same server the site runs on, which mostly measures whether the server can talk to itself.
The math itself is simple. Availability = successful checks ÷ total checks, over the window. Keep the raw results long enough to audit an incident (we keep 90 days), and keep daily aggregates - uptime percentage, average latency - forever, because trends over a year tell you things single incidents can't.
What should a small business actually aim for?
Honest numbers, from running services on ordinary infrastructure:
- 99.9% monthly is achievable on a single well-run server. It requires: fast detection (a monitor with 1-minute checks and alerts you'll actually see), boring discipline about deployments, and expiry monitoring for certs and domains so calendar-driven outages never happen.
- 99.99% is a different sport. It implies redundancy at every layer - two of everything, load balancing, automated failover, and deployments that never take the service down. For most small products, the money is better spent on detection and recovery speed than on the fourth nine.
- What kills small sites is not the nines - it's the silent weeks. One undetected outage of three days (a real thing; see our post on silent downtime) costs you 99.6% for the year, more than a hundred well-handled small incidents combined.
Translate, always
The whole trick to reading uptime claims is a single reflex: convert the percentage into minutes for the window you care about, and ask what happens in the fine print - measurement window, maintenance exclusions, and what "available" means. 99.9% is 44 minutes a month. 99.99% is 4. Everything else is marketing typography.
And measure your own. A number you computed from your own checks beats any badge on someone else's status page.