Nines and downtime

Availability is the fraction of time, or of requests, that a system works correctly. People quote it in nines. 99.9% is "three nines," and 99.99% is "four nines." The number looks abstract, but it turns directly into minutes of allowed downtime.

The big idea

Each extra nine cuts the allowed downtime by a factor of ten. Think of a monthly budget for things going wrong. A 99.9% target gives you a small budget. A 99.99% target gives you a tiny one.

The useful way to read the table is to ask whether a human can fix the problem in the budget. At four nines, 4.3 minutes a month is less time than it takes most teams to get paged and open a laptop. A service at that level needs automatic failover and rollbacks that finish in seconds.

The right target depends on the service. An internal reporting tool at 99.5% is fine. A payment authorization path probably needs 99.99%.

Walking through it

Allowed downtime, using a 30-day month of 43,200 minutes:

The arithmetic for one row:

allowed downtime = (1 − availability) × minutes in the window
99.9% per month  = 0.001 × 43,200 = 43.2 minutes
99.99% per month = 0.0001 × 43,200 = 4.32 minutes

Availability can be measured two ways. By time asks, "was the service up for 99.9% of minutes?" By requests asks, "did 99.9% of requests succeed?" Request-based measurement is usually more useful. An outage at 3 a.m. hurts fewer users than the same outage at noon, and request counts reflect that.

Common mistakes

• Quoting a number with no window or measure. "Five nines" means nothing until you know whether it's per month, and whether it counts minutes or requests.
• Assuming 99.9% allows an hour a month. It allows about 43 minutes. An hour-long outage breaks it on its own.
• Treating each nine as cheap. Each extra nine usually costs more automation, redundancy and testing than the one before.

Check yourself

1. How many minutes a month does 99.9% allow? About 43 minutes in a 30-day month.
2. Why can request-based availability be more useful than time-based? Outages hurt different numbers of users at different hours, and request counts capture that.

Key takeaways

• Each extra nine cuts allowed downtime tenfold.
• At four nines, you need automated failover and fast rollbacks, not manual fixes.
• Define the window and the measure, time or requests, before you quote a number.

Further learning

The Google SRE book table of contents covers how teams set and manage availability targets.

Next, read about MTBF and MTTR, which explains how recovery time moves the number.