A good uptime percentage for a production web service is 99.9% or better. That allows 8 hours 46 minutes of downtime per year. Customer-facing revenue systems should target 99.95% or 99.99%. Internal tools can live with 99.5%.
The right number for you depends on three things: what the service does, who depends on it, and what an hour of downtime costs. Uptime is measured as the share of a time window in which the service was available, so the difference between 99% and 99.9% sounds like rounding noise. It is not. Each extra nine cuts your allowed downtime by a factor of ten, and roughly multiplies what it costs to deliver by the same factor.
The nines table: what each percentage really allows
Percentages hide the pain. Clock time does not. Here is what each common uptime level permits before the number is broken:
| Uptime | Downtime per year | Per month | Per week |
|---|---|---|---|
| 99% | 3.65 days | 7h 18m | 1h 41m |
| 99.9% | 8h 46m | 43m 50s | 10m 5s |
| 99.95% | 4h 23m | 21m 55s | 5m 2s |
| 99.99% | 52m 36s | 4m 23s | 1m 1s |
| 99.999% | 5m 15s | 26s | 6s |
To translate any other percentage into hours and minutes of allowed downtime, use the calculator:
alertping ▸ downtime calculator
- allowed downtime per year
- 52m 36s
- per quarter
- 13m 9s
- per month
- 4m 23s
- per week
- 1m 1s
- per day
- 8.6s
A 5-minute check interval can miss a whole month of budget at four nines. AlertPing checks every 30 seconds, so the number above is one you can actually measure.
Read the monthly column first, because most SLAs are measured in monthly windows. At 99.9% you get 43 minutes 50 seconds a month: one bad deploy and a slow rollback can spend it in a single afternoon. At 99.99% you get 4 minutes 23 seconds a month, which means no human can respond fast enough on their own. Detection, confirmation and failover have to happen in seconds.
Uptime benchmarks by industry
Targets cluster by how directly downtime turns into lost money or broken contracts:
- SaaS products: 99.9% to 99.99%. Paid B2B plans usually promise 99.9% in the contract; infrastructure-grade products promise four nines.
- E-commerce: 99.95% or better. Every minute of checkout downtime is revenue that mostly does not come back, and peak hours make the average misleading.
- APIs and platforms: 99.99%. Other people's products break when yours does, so your downtime multiplies downstream.
- Internal tools: 99.5% is usually fine. If the wiki is down for two hours on a Sunday night, nobody outside the building notices.
- Marketing sites: 99.9%. Cheap to achieve on static hosting, and a down homepage quietly burns your ad spend.
If a customer contract hangs on the number, read our breakdown of the 99.99 uptime meaning and SLA mechanics before you sign anything. For the tier most contracts actually land on, we unpack what 99.9 percent uptime means in practice.
What each nine costs to achieve
The nines are not a dial you turn. Each level demands a different class of engineering and operations:
- 99% (two nines): any reasonable host delivers this by default. If you are below 99%, you have a hosting problem, not an architecture problem.
- 99.9% (three nines): solid managed hosting, deploy discipline with fast rollback, and monitoring that detects an outage in under a minute with a person who actually responds.
- 99.95%: redundancy at every layer: at least two instances behind a health-checked load balancer, a database with a tested failover, staged rollouts.
- 99.99% (four nines): multi-zone infrastructure, automated failover, an on-call rotation with escalation, and change management. The 4-minute monthly budget removes humans from the detection loop.
- 99.999% (five nines): multi-region active-active architecture and a dedicated reliability function. Almost never worth it for a web product; this is telecom and payment-network territory.
A useful rule of thumb: each additional nine costs roughly ten times more to deliver than the previous one, while the visible benefit to a customer shrinks. Going from 8 hours of downtime a year to 52 minutes is very noticeable. Going from 52 minutes to 5 minutes is not, unless you are running other people's infrastructure.
alertping
Find out what your uptime actually is
AlertPing checks your site every 30 seconds from 3 regions and turns the result into an uptime percentage you can put in front of customers. First check runs within a minute.
How to choose a realistic target
Pick the target after you know your baseline, not before. Teams that declare 99.99% without measuring usually discover they were running at 99.7% all along. Two rules keep the target honest:
- Promise less than you build. Set your internal objective one level stricter than the number in customer contracts. Target 99.95% internally, promise 99.9% externally, and the SLA survives a bad month.
- Price the gap. If an hour of downtime costs you $300, engineering four nines makes no sense. If it costs $30,000, three nines is negligence.
One more nuance: decide what "down" means before you measure. A homepage returning 200 while checkout throws errors is down where it matters. Define uptime per critical path, login, checkout, API, not per server, and hold each path to its own target. A blended number across everything you host flatters the average and hides exactly the failures your customers feel first.
Turning the target into an error budget
A percentage on a slide changes nothing. What makes a target operational is reading it backwards: whatever you did not promise is an allowance you are permitted to spend. Commit to 99.9% and you have granted yourself 43 minutes and 50 seconds of downtime a month. That allowance is your error budget, and it is the same number as the target, expressed in a unit people can actually make decisions with.
The reason to frame it this way is that it settles the argument between shipping and stability without anyone having to win it. Two thirds of the budget gone by the 12th means the risky migration waits. A month that ends at 5% consumption means the target is loose enough that you could be moving faster. Teams also track how fast they are spending, which is called burn rate, and alert on that rather than on raw downtime, because a slow leak that never trips a threshold is what quietly eats a month. The mechanics, including the burn-rate thresholds Google publishes and what an error budget policy needs to say, are in our guide to error budgets.
How to measure your uptime percentage
Self-reported uptime from the same infrastructure that fails is worth little. Measure from the outside, the way your users reach you, with a website monitoring tool that probes from multiple regions. If the number backs a contract, treat it as SLA monitoring and hold it to the same rules. Two details decide whether the number is credible:
- Check interval sets your resolution. A 5-minute interval cannot see a 3-minute outage, so it quietly inflates your uptime. 30-second checks catch what actually happened.
- Confirmation prevents false downtime. A single vantage point counts its own network hiccups as your outages. Requiring agreement from several regions, the way uptime monitoring works at AlertPing, keeps the record clean in both directions.
For the full setup, from check types to status page, follow the step-by-step guide on how to monitor website uptime.
The short version: a good uptime percentage is one you measure honestly, can afford to deliver, and are willing to defend in a contract. For most production services, that number starts at 99.9%.