What does 99.9% uptime actually mean?
A plain-English guide to uptime percentages: how much downtime each of the nines really allows, why the math surprises people, and how to think about SLAs without fooling yourself.
Every status page and hosting plan advertises a number with a string of nines in it. Three nines, four nines, the legendary five. They get quoted in sales decks and pasted into service agreements as if everyone agrees on what they mean. Most people do not, and the gap between “99.9%” and “99.99%” is bigger than the extra nine makes it look.
This is a guide to reading those numbers honestly. How much downtime each tier actually allows, why a single extra nine costs so much more than the last one, and how to set a target you can defend instead of one that sounds good on a slide.
The number is just downtime, rearranged
Uptime percentage is a measurement of how much of a period your service was available. If you were up for 999 minutes out of every 1000, that is 99.9% uptime. The percentage is the easy part. The part that trips people up is converting it back into wall-clock time, because a figure that close to 100 feels like “basically never down” right up until you do the arithmetic.
A year has 525,600 minutes. One tenth of one percent of that is 525.6 minutes, which is about 8 hours and 46 minutes. So a service running at exactly 99.9% over a year can be completely offline for the better part of a working day and still hit its target. That surprises people who read 99.9% as “rounds up to perfect.”
Here is what each common tier allows, per year and per month, so you can see the jumps:
| Uptime | Downtime per year | Downtime per month | Downtime per day |
|---|---|---|---|
| 99% (two nines) | ~3.65 days | ~7.2 hours | ~14.4 minutes |
| 99.9% (three nines) | ~8.77 hours | ~43.8 minutes | ~1.4 minutes |
| 99.95% | ~4.38 hours | ~21.9 minutes | ~43 seconds |
| 99.99% (four nines) | ~52.6 minutes | ~4.4 minutes | ~8.6 seconds |
| 99.999% (five nines) | ~5.26 minutes | ~26 seconds | ~0.86 seconds |
Two things jump out of that table. The first is that 99% is a weak promise. It sounds like an A grade, but it permits over three and a half days of outage a year, which any real customer would notice and remember. The second is that the nines are not evenly spaced. Each one you add cuts your allowed downtime by a factor of ten, so the engineering effort does not climb in a straight line. It climbs a cliff.
Why the last nine costs the most
Getting from 99% to 99.9% is mostly about not doing anything obviously careless. Use a host that does not fall over weekly, deploy without taking the site down, restart cleanly when a process dies. A small team can hit three nines with sensible defaults and a bit of attention.
Getting from 99.9% to 99.99% is a different category of work. Your yearly budget drops from nearly nine hours to under an hour, which means a single bad deploy or one slow database migration can blow the whole year in an afternoon. To hold four nines you need redundancy with no single point of failure, automated failover that works without a human awake to trigger it, and deploys that cannot take the service down even when they go wrong. That is real architecture and real cost.
Five nines, around five minutes of downtime for the entire year, is the territory of multi-region systems with automatic traffic shifting and teams who rehearse failure. Very few products genuinely need it, and most of the ones that claim it are measuring in a way that quietly excludes the outages that would ruin the number. Which brings us to the most important part.
The percentage means nothing without the definitions
A nine is only as honest as the fine print behind it. Two services can both advertise 99.9% and measure completely different things. Before you trust a number, your own or a vendor’s, you need answers to four questions.
What counts as “down”? Is it only a hard failure where the server returns nothing, or does a slow response count too? A site that takes thirty seconds to load is useless to the person waiting, but most naive uptime math calls it up because a 200 eventually came back. If “available” does not include “fast enough to use,” the number is flattering itself.
What is being measured, and from where? A health check that hits a static file will stay green while the database behind it is on fire. A check that runs inside the same data center as the app goes down with it and reports nothing. Honest uptime is measured from outside your infrastructure, against a URL that actually exercises the app, not a heartbeat that proves only that one process is alive.
Over what window? A monthly figure resets the budget every month, so a four-hour outage in March is forgotten by April. A trailing 90-day or annual figure remembers it. Vendors quote whichever window makes them look better. When you set your own target, pick the window that matches how your customers actually feel pain, which is usually the rolling one, because nobody forgives an outage just because the calendar flipped.
What is excluded? This is where most published SLAs do their real work. “Scheduled maintenance” often does not count against the number, so a vendor can take you offline every Sunday at 2am and still claim five nines. Neither do outages “outside our control,” which can be stretched to cover a lot. The exclusions matter more than the headline, because they decide which of your actual outages the number is allowed to ignore.
None of this means the percentages are useless. It means a nine without its definitions is marketing, and a nine with them is an engineering target.
Uptime versus an SLA versus an error budget
These three terms get used as if they are the same thing. They are related but distinct, and keeping them separate makes the whole topic easier to reason about.
Uptime is the measurement. It is what actually happened, the percentage of time the service was available over some window.
An SLA, a service level agreement, is a promise about that measurement, usually with a penalty attached. “We guarantee 99.9% monthly uptime, and if we miss it you get a credit.” An SLA is a contract. It is the number you are willing to be held to, which is why it should always be lower than what you actually achieve. You never promise your best case.
An error budget is the clever inversion of the target. If your goal is 99.9% over a month, your error budget is the other 0.1%, which is about 43 minutes of allowed downtime. That budget is a resource you get to spend. It reframes reliability from “never go down,” which is impossible and paralyzing, into “stay within 43 minutes this month,” which is a number you can actually manage. When the budget is healthy you can ship riskier changes faster. When you have burned most of it, you slow down and stabilize. The budget turns an abstract percentage into a day-to-day decision about how fast to move.
How to pick a target you can defend
Resist the urge to write down the biggest number you can imagine. A target you miss is worse than a humble one you keep, because the first thing an unmet SLA does is teach your customers not to trust your status page. Work it out from the actual stakes instead.
Start with what an hour of downtime really costs. For a marketing site the honest answer is often “not much,” and 99.9% is plenty. For a checkout flow or a paid API that other products depend on, an hour offline costs real revenue and real trust, and the extra nine is worth the work. Match the target to the blast radius, not to your pride.
Then measure what you already do before you promise anything. Run an external check for a couple of months and look at the real figure. If you are quietly sitting at 99.7% today, publishing a 99.99% SLA is writing a cheque your architecture cannot cash. The promise should trail the measurement, with margin to spare.
And measure it the way your users feel it. Probe from outside your network, on a tight interval, against a URL that touches the parts that matter. Count “too slow to use” as down. Wait for a couple of consecutive failures before you call an outage so a one-second network blip does not dent the number, but do not paper over the real ones. The goal is a figure you would be comfortable showing a customer, not one tuned to look good. See how to monitor website uptime for the mechanics of checks that measure honestly.
The short version
A nine is downtime, rearranged into a percentage that flatters itself. 99.9% sounds airtight and still leaves room for almost nine hours of outage a year. Each extra nine costs roughly ten times the effort of the one before it, and the published figure means nothing until you know what counts as down, where it is measured from, over what window, and what is excluded. Pick a target from what an outage actually costs you, measure what you really do first, and treat the gap between your target and 100% as a budget you spend deliberately rather than a line you pretend you will never cross.
If you want to know your own number instead of guessing at it, you can find out for free. Cronaut probes your site from outside your infrastructure, records uptime and latency over time, and shows you the real percentage your customers experience. The free plan is enough to start watching a site today, and the same engine keeps an eye on your cron jobs and SSL certificates in the same place. Point it at one URL, let it run for a month, and you will have an honest figure to build your target on.