Uptime Percentage Explained: 99.9% vs 99.99% in Minutes
"Three nines" and "four nines" sound close, but the difference between 99.9% and 99.99% uptime is the difference between about 44 minutes of downtime a month and about 4. This article turns the common uptime percentages into concrete downtime budgets, shows why the number you measure depends on how often you check, explains how to word an SLA so it means something, and shows how the availability of services you depend on multiplies into your own.
The downtime budget table
Allowed downtime is simply (1 - uptime) x period. The table below uses these assumptions: a day is 24 hours, a week is 7 days, a month is the average month of 30.44 days (365.25 / 12), and a year is 365 days. Values are rounded to the nearest second.
| Uptime | Per day | Per week | Per month (30.44 d) | Per year (365 d) |
|---|---|---|---|---|
| 99% ("two nines") | 14m 24s | 1h 40m 48s | 7h 18m 20s | 3d 15h 36m |
| 99.5% | 7m 12s | 50m 24s | 3h 39m 10s | 1d 19h 48m |
| 99.9% ("three nines") | 1m 26s | 10m 5s | 43m 50s | 8h 45m 36s |
| 99.95% | 43s | 5m 2s | 21m 55s | 4h 22m 48s |
| 99.99% ("four nines") | 9s | 1m 0s | 4m 23s | 52m 34s |
| 99.999% ("five nines") | 0.9s | 6s | 26s | 5m 15s |
If your contract defines a month as a calendar month, the budget changes slightly: a 30-day month at 99.9% allows 43m 12s, a 31-day month 44m 38s. Always state which definition you use.
Two things stand out. First, each extra nine cuts the budget by ten. Second, at 99.99% a single bad deploy that takes five minutes to roll back already breaks the monthly target. Four and five nines are not reached by fixing things quickly; they require redundancy, so that a failure does not cause downtime at all.
Which target is realistic?
- 99%–99.5%: a single server with no failover, manual recovery, occasional maintenance during business hours. Fine for internal tools and small sites.
- 99.9%: a common target for a well-run single-region site with monitoring, alerts and a practiced recovery process. One serious incident a month can consume most of the budget.
- 99.95%–99.99%: requires redundant servers behind a load balancer, zero-downtime deploys, automated failover for the database, and alerting that reaches someone within minutes.
- 99.999%: five minutes a year. This is the territory of multi-region architectures and dedicated operations teams. Promising it on a single server is not credible.
Measured uptime depends on how often you check
Uptime monitors do not watch your site continuously; they sample it. That sampling has two consequences that are easy to overlook.
Resolution: how much one check represents
With checks every 5 minutes, there are about 8,767 checks in an average month, so each failed check stands for roughly 0.0114% of the month. With 1-minute checks there are about 43,834. Compare that with the budgets above:
| Check interval | Checks per month | Failed checks allowed at 99.9% | Failed checks allowed at 99.99% |
|---|---|---|---|
| 15 minutes | ~2,922 | ~2.9 | ~0.3 |
| 5 minutes | ~8,767 | ~8.8 | ~0.9 |
| 1 minute | ~43,834 | ~43.8 | ~4.4 |
A single failed 5-minute check already exceeds a 99.99% monthly budget. In other words, you cannot meaningfully verify four nines with 5-minute checks: your measurement is coarser than the thing you are measuring.
Blind spots: outages between checks
An outage that starts and ends between two checks is never seen. With 5-minute checks, a 3-minute outage may produce zero failed checks or one, depending on timing. So low-frequency monitoring tends to overstate uptime for sites with many short blips, while a single failed check can overstate downtime by counting a 30-second hiccup as a full interval.
Confirmation rules change the number too
Many teams require several consecutive failures before declaring an incident, to avoid alerting on a single network glitch. That is good for alert quality, but decide whether the confirmation period counts as downtime in your reports. Whatever you choose, write it down and apply it consistently. If you are choosing an interval, our guide to choosing a monitoring interval goes through the trade-offs, and detecting flapping websites covers the short blips that never become incidents.
One vantage point is one opinion
A monitor that checks from a single location measures availability as seen from that location. A routing problem between the monitor and your host looks like downtime even when other users can reach you, and a regional outage elsewhere can go unseen. Keep this in mind when an uptime figure is used for anything contractual.
How to word an SLA so it means something
"99.9% uptime guaranteed" on its own is almost meaningless. A useful service level agreement defines how availability is measured and what happens when the target is missed. Cover at least these points:
- Measurement window — calendar month, in which time zone.
- What counts as unavailable — for example, the service URL returns a 5xx status, times out after 30 seconds, or fails to connect, as observed by the provider's monitoring.
- Minimum duration — whether a single failed check counts, or only failures confirmed over a number of consecutive checks or minutes.
- Exclusions — scheduled maintenance announced in advance (with a notice period and a monthly cap), outages caused by the customer, and events outside the provider's reasonable control.
- Remedy — service credits per tier, how to claim them, and the claim deadline.
An example of the core clause:
"Monthly Uptime Percentage" means the total number of minutes in a calendar month (UTC), minus the number of minutes of Downtime, divided by the total number of minutes in that month. "Downtime" means any period of at least two consecutive minutes during which the Service URL returns an HTTP 5xx status code or does not respond within 30 seconds, as measured by the Provider's external monitoring at one-minute intervals, excluding Scheduled Maintenance announced at least 48 hours in advance and not exceeding four hours per month.
This is an illustration of structure, not legal advice. Notice how it fixes the interval, the failure definition, the confirmation period and the exclusions. Without those, both sides can produce different "uptime" numbers from the same month. If you exclude planned maintenance, record it as such: maintenance windows keep planned work out of your alerts. In Uptime Monitor, checks logged during a window still count as not up in the uptime percentage, so subtract them if your SLA excludes maintenance.
Composite availability: your dependencies multiply
Your site's availability is limited by everything it needs to work. If components are in series (all must be up), and their failures are independent, multiply their availabilities:
Composite = A1 x A2 x ... x An
Example: app server 99.9%, database 99.95%, DNS provider 99.99%
0.999 x 0.9995 x 0.9999 = 0.99840 -> 99.84%
About 70 minutes of expected downtime per average month.None of the three components is below 99.9%, yet the combination is. Five services at 99.9% each give 0.999 to the fifth power ≈ 99.50% — about 3h 39m a month. Every external API, payment gateway or authentication provider in the critical path adds a factor.
If components are in parallel (any one is enough, such as two servers behind a load balancer), the system fails only when all fail:
Composite = 1 - (1 - A1) x (1 - A2)
Example: two independent servers at 99.5% each
1 - (0.005 x 0.005) = 0.999975 -> 99.9975%That is why redundancy is the route to more nines. The big caveat is independence. Two servers that share a deploy pipeline, a database, a DNS provider or a data center fail together more often than the formula suggests. Real-world composite availability is usually lower than the parallel calculation and should be checked against what your monitoring actually measures.
FAQ
How much downtime is 99.9% uptime?
About 43 minutes 50 seconds per average month (30.44 days), 10 minutes 5 seconds per week, or 8 hours 45 minutes 36 seconds per 365-day year.
Does scheduled maintenance count against uptime?
Only if your SLA says so. Many SLAs exclude announced maintenance up to a cap; your internal reports should show it separately either way so it stays honest.
Why does my provider's uptime differ from my monitor's?
Different check intervals, locations, failure definitions and maintenance exclusions. Compare definitions before comparing numbers.
Key takeaways
- Each extra nine divides the downtime budget by ten: 99.9% is ~43m 50s a month, 99.99% is ~4m 23s.
- Measured uptime is limited by the check interval; 5-minute checks cannot verify 99.99%.
- An SLA must define the window, failure criteria, confirmation period, exclusions and remedy.
- Dependencies in series multiply: several 99.9% services make a sub-99.9% site.
- Redundancy adds nines only when failures are truly independent.
Uptime Monitor checks your sites at intervals from one minute (Professional plan) to daily, shows uptime percentages and recent checks on the dashboard, and lets you schedule maintenance windows so planned work does not trigger alerts. A configurable fail threshold sets how many consecutive failures confirm an outage. Public status pages let customers see your history for themselves. See plans and check intervals.
