"Three Nines" Sounds Great. How Much Downtime Is That?

Cloud providers and SaaS products promise "99.9% uptime" or "four nines." The numbers look almost identical, but each extra nine means ten times less allowed downtime, and usually a lot more engineering and money.

This post turns the nines into minutes, shows why a system is often less reliable than its parts, and how redundancy and error budgets change the math.


๐ŸŽฏ Quick Answer (30-Second Read)

  • 99.9% = about 8.8 hours of downtime a year (43.8 minutes a month).
  • 99.99% = about 52.6 minutes a year (4.4 minutes a month).
  • 99.999% = about 5.3 minutes a year.
  • Dependencies multiply: three services at 99.9% each, all required โ†’ about 99.7% total.
  • Redundancy helps: two independent 99% servers where either one is enough โ†’ 99.99%.
  • Error budget = the downtime your target allows; spend it on shipping changes, stop when it runs out.

The Nines Table

Availability Downtime per year Per month (30.4 days) Per week
99% ("two nines") 3.65 days 7.3 hours 1.7 hours
99.5% 1.83 days 3.65 hours 50 min
99.9% ("three nines") 8.77 hours 43.8 min 10.1 min
99.95% 4.38 hours 21.9 min 5 min
99.99% ("four nines") 52.6 min 4.4 min 1 min
99.999% ("five nines") 5.26 min 26.3 s 6 s

The formula: allowed downtime = (1 โˆ’ availability) ร— time period. For a year: 0.001 ร— 525,960 minutes โ‰ˆ 526 minutes โ‰ˆ 8.77 hours.

xychart-beta title "Allowed downtime per month (minutes)" x-axis ["99%", "99.5%", "99.9%", "99.95%", "99.99%"] y-axis "Minutes" 0 --> 450 bar [438, 219, 43.8, 21.9, 4.4]
Key takeaway: at 99.99%, a single 5-minute outage blows your whole month's budget. No human can even open a laptop and respond that fast, so four nines requires automatic failover.

Dependencies Multiply (in the Wrong Direction)

If a request needs all of these to work, their availabilities multiply:

flowchart LR U["User"] --> LB["Load balancer
99.99%"] --> APP["App
99.9%"] --> DB[("Database
99.9%")] APP --> PAY["Payment API
99.9%"]

Total โ‰ˆ 0.9999 ร— 0.999 ร— 0.999 ร— 0.999 โ‰ˆ 99.69%

That's about 27 hours of downtime a year, worse than any single part. Every hard dependency you add lowers the ceiling.

How to fight it:

  • Make non-critical dependencies optional (graceful degradation)
  • Use timeouts and circuit breakers so a slow dependency doesn't take you down (Circuit Breaker Pattern)
  • Do work asynchronously via queues where users don't need an instant answer

Redundancy Adds Nines

If two components are redundant (either one can serve) and fail independently:

Unavailability = (1 โˆ’ Aโ‚) ร— (1 โˆ’ Aโ‚‚)

Setup Calculation Availability
One server at 99% โ€” 99%
Two independent servers at 99% 1 โˆ’ (0.01 ร— 0.01) 99.99%
Three at 99% 1 โˆ’ 0.01ยณ 99.9999%
flowchart LR LB["Load balancer"] --> S1["Server A
99%"] LB --> S2["Server B
99%"] S1 --> R["Either one works โ†’
99.99% for this layer"] S2 --> R

The catch: "independent." If both servers sit in the same data centre, share a database, or receive the same bad deploy, they fail together, and the math collapses. That's why real redundancy means multiple availability zones, regions, staged rollouts and no shared single points of failure.


SLA, SLO and Error Budgets

Term Meaning Example
SLI (indicator) What you measure % of requests that succeed within 300 ms
SLO (objective) Your internal target 99.9% per 30 days
SLA (agreement) Contractual promise, with penalties 99.5%, credits if missed
Error budget 100% โˆ’ SLO 0.1% = 43.8 min/month

Google's SRE practice popularised error budgets: if you still have budget, ship features and take risks. If you've used it up, slow down and focus on reliability. It turns "how reliable should we be?" into a shared, measurable agreement.


How Many Nines Do You Need?

  • Internal tools, early startups: 99.5โ€“99.9% is usually fine.
  • Consumer apps: 99.9โ€“99.95%.
  • Payments, core infrastructure: 99.99%+, with automatic failover.
  • Remember the cost: each nine typically requires more redundancy, automation, testing and on-call effort. Users also can't tell 99.999% from 99.99% if their own phone network is less reliable than both.

Frequently Asked Questions

How much downtime is 99.9% uptime?

99.9% availability allows about 8.77 hours of downtime per year, about 43.8 minutes per 30.4-day month, or about 10 minutes per week.

How do you calculate the availability of a system with multiple components?

For components that must all work, multiply their availabilities: three services at 99.9% give about 99.7%. For redundant components where any one is enough, multiply their unavailabilities and subtract from 1: two independent 99% servers give 99.99%.

What is the difference between SLA and SLO?

An SLO is an internal reliability target, such as 99.9% of requests succeeding over 30 days. An SLA is a contractual commitment to customers, usually set lower than the SLO, with penalties such as service credits if it isn't met.


Conclusion

Each extra nine cuts allowed downtime tenfold, from 8.8 hours a year at 99.9% to 53 minutes at 99.99%. Dependencies multiply availability downward, while truly independent redundancy multiplies it upward. Set SLOs your users actually need, and use error budgets to balance shipping speed against reliability.


Sources

Last verified: 2 November 2026.


Related reads: Why Netflix Rarely Goes Down ยท Circuit Breaker Pattern Explained ยท Load Balancer Explained ยท Horizontal vs Vertical Scaling

I explain the tech and math behind products. Follow on LinkedIn or X, or invite me to speak.