Cover photo by the blowup on Unsplash.
I build an uptime monitor, so this question lands in my inbox a lot: is 98% uptime good?
For a public website or a paid API, no. For an internal tool or a side project, it is fine. The difference is one division away.
98% looks like a top grade because school taught us that 98 out of 100 is excellent. Uptime does not grade like school. The whole scale for public services lives between 99% and 100%, and serious targets differ only in the digits after the decimal. On that scale, 98% sits at the bottom.
Turn the percentage into time
The allowed failure at 98% is 2%. Two percent of a year is 7.3 days. Two percent of a 30-day month is 14.4 hours. If your shop makes 2,000 USD a day, 98% uptime means you accept about $14,600 of closed-door time per year and the target still counts as met.
Here is the same math for every common target. The last column prices the downtime for that $2,000-a-day shop.
| Uptime | Per day | Per 30-day month | Per year | Lost sales per year |
|---|
| 90% | 2.4 hours | 3 days | 36.5 days | $73,000 |
| 95% | 1.2 hours | 36 hours | 18.3 days | $36,500 |
| 98% | 28.8 minutes | 14.4 hours | 7.3 days | $14,600 |
| 99% | 14.4 minutes | 7.2 hours | 3.7 days | $7,300 |
| 99.5% | 7.2 minutes | 3.6 hours | 1.8 days | $3,650 |
| 99.9% | 1.4 minutes | 43 minutes | 8.8 hours | $730 |
| 99.95% | 43 seconds | 21.6 minutes | 4.4 hours | $365 |
| 99.99% | 8.6 seconds | 4.3 minutes | 52.6 minutes | $73 |
| 99.999% | 0.9 seconds | 26 seconds | 5.3 minutes | $7 |
Two jumps on this table do most of the work in real contracts. From 98% to 99.9%, the allowed downtime drops from 14.4 hours a month to 43 minutes. From 99.9% to 99.99%, it drops from 43 minutes to 4.3 minutes, and that second jump usually costs about ten times more engineering than the first while saving the shop $657 a year.
The shape of the downtime matters
98% per month is 14.4 hours, but the number says nothing about how those hours land.
Thirty minutes of planned maintenance every night at 03:00 adds up to 98% and most users never notice. One 14-hour outage on the day of your product launch is also 98%. Same score, very different month.
So a single uptime percentage is a summary, not the full story. When someone quotes you a number, also ask about the longest single outage and when it happened.
When 98% is enough
Plenty of systems can live at 98% and nobody gets hurt:
- An internal wiki. People retry after lunch.
- A staging environment. Downtime there is often planned.
- A batch job that builds reports at night. It has hours of slack before anyone reads the output.
- A home server on a residential connection. Your power company already decided your uptime for you.
The shared pattern: when these go down, nobody loses money and nobody loses trust. Paying for more nines there is waste.
When it is not
A checkout page, a paid API, a login service. Here 98% fails twice. First the direct cost: 14.4 hours a month of failed requests and support tickets. Second the trust cost, which is larger and slower. A customer who hits your outage twice in one week does not check your uptime report. They remember that your service is the one that breaks.
One more trap: an SLA is not uptime. Uptime is the measured number. An SLA is a contract promise with a penalty, and the penalty is almost always a service credit. If a provider misses its 99.9% SLA, you get part of your bill back. Your customers get nothing.
What to aim for instead
99.9% is the default target for customer-facing services for a reason. 43 minutes a month is enough room for a bad deploy and a couple of small failures, and a small team can hit it without heroics. Above that, each nine costs roughly ten times more and most users cannot feel the difference.
If you want to run your own numbers, I keep a free uptime SLA calculator and an error budget calculator on our site; both work without signup.
What target do you actually run in production, and did you pick it or inherit it? I am curious how many teams measured before they promised.
