Availability and the Nines

Availability is the fraction of time (or, better, the fraction of requests) that a service is working, and by long convention it is quoted in “nines” — 99% is “two nines,” 99.9% is “three nines,” 99.99% is “four nines,” 99.999% is “five nines.” Each extra nine cuts the allowed failure by a factor of ten, which is why the vocabulary is logarithmic and why the cost of each nine is roughly ten times the previous one. The single most useful thing this vocabulary buys you is an intuition for how much downtime a target actually permits: three nines is about 8.76 hours of downtime per year, four nines is about 52.6 minutes per year, and five nines is about 5.26 minutes per year (SRE Book, Availability Table). Availability is not a thing you maximize; it is a number you choose, because past the point where users can perceive the difference, additional nines are pure wasted spend — the marginal nine can cost 10–100× the previous one for reliability the user will never notice (Beyer et al. 2016, ch. 3). This note is the arithmetic and judgment behind the target; the framework that uses the number — SLIs, SLOs, error budgets — lives in Service Level Objectives, and the measurement signals behind it are the four golden signals.

Mental Model

Think of an availability target as a downtime budget denominated in time. If you promise 99.9% over a year, you are promising to be down no more than 0.1% of the year — and 0.1% of a year is 8.76 hours. That budget is the thing every downstream reliability decision spends: a risky deploy, a maintenance window, a dependency outage all draw from it. The nines are just a compact way of writing the budget, and because they are a logarithm of the unavailability, adding a nine divides the budget by ten.

flowchart LR
    A["Availability target<br/>(a chosen number, not a max)"]
    A --> B["Unavailability = 1 − A<br/>(the error budget)"]
    B --> C["Downtime budget<br/>per year / month / week"]
    C --> D["Spent by: deploys,<br/>incidents, maintenance,<br/>dependency failures"]
    A -. "each +1 nine<br/>= budget ÷ 10<br/>= cost ×10-100" .-> A

What it shows and the insight to take: the target is an input you pick, and everything to its right is derived. Unavailability (1 − A) is the budget; converting it to wall-clock time makes it concrete; and the self-loop is the economic reality — every nine you add shrinks the downtime budget tenfold and raises the engineering cost by roughly one to two orders of magnitude. The insight is that “how available should this be?” is a product and cost decision made deliberately, not a reflexive “as available as possible” — because “as possible” is infinitely expensive and, past a point, invisible to users.

The Nines Table — Downtime per Year and Below

The core reference every SRE memorizes is the mapping from a nines target to allowed downtime. These figures assume continuous expected operation (a 24×7 service). The canonical version is the SRE Book’s availability table (Appendix A):

Availability	“Nines”	Downtime / year	/ quarter (90d)	/ 30 days	/ week	/ day
90%	one nine	36.5 days	9 days	3 days	16.8 h	2.4 h
99%	two nines	3.65 days	21.6 h	7.2 h	1.68 h	14.4 min
99.5%	—	1.83 days	10.8 h	3.6 h	50.4 min	7.2 min
99.9%	three nines	8.76 h	2.16 h	43.2 min	10.1 min	1.44 min
99.95%	—	4.38 h	1.08 h	21.6 min	5.04 min	43.2 s
99.99%	four nines	52.6 min	12.96 min	4.32 min	60.5 s	8.64 s
99.999%	five nines	5.26 min	1.30 min	25.9 s	6.05 s	0.87 s

The numbers are just arithmetic on a 525,600-minute year. The derivation for any level: allowed downtime per year = (1 − availability) × 525,600 minutes. So for 99.99%, 0.0001 × 525,600 = 52.56 minutes; for 99.999%, 0.00001 × 525,600 = 5.256 minutes; for three nines, 0.001 × 8,760 hours = 8.76 hours. Scaling to a shorter window is proportional: the 30-day figure is (1 − availability) × 43,200 minutes. A secondary source cross-checks these to the same values, defining the “class of nines” formally as c = ⌊−log₁₀(1 − A)⌋ (Wikipedia, High availability) — i.e. the number of leading nines is the floor of the negative base-10 logarithm of the unavailability, which is exactly why 99% is two, 99.9% is three, and so on.

Two practical readings of the table. First, the jump between adjacent nines is a factor of ten in downtime — three nines gives you most of a workday of downtime a year, four nines gives you under an hour, five nines gives you barely enough time to notice an incident before it must already be resolved. Second, five nines is essentially incompatible with human response: 5.26 minutes per year is less time than it takes an on-call engineer to read a page, open a laptop, and diagnose — which means five-nines services must fail over automatically, with no human in the recovery loop (see Redundancy and Failover Strategies and Mean Time to Detect and Recover).

Time-Based versus Request-Based (Aggregate) Availability

There are two fundamentally different ways to compute the availability number, and confusing them is a classic error.

Time-based availability is the traditional formula: the proportion of wall-clock time the system was up.

availability_time = uptime / (uptime + downtime)

This is intuitive and is what SLAs with maintenance-window language usually mean. But it breaks down for large distributed systems, for a reason the SRE Book makes explicit: a globally distributed service is almost never entirely up or entirely down (Beyer et al. 2016, ch. 3). At any instant some fraction of requests in some region are failing while the rest succeed. “Is the system up right now?” has no single yes/no answer, so “fraction of time up” is not well-defined.

Request-based (aggregate) availability — Google’s preferred metric for serving systems — sidesteps this by measuring success at the granularity of individual requests:

availability_request = successful_requests / total_valid_requests

The SRE Book’s worked figure: a service handling 2.5 million requests a day with a 99.99% target may fail up to 250 requests that day and still meet the objective (Beyer et al. 2016, ch. 3). This “yield”-style metric is superior for three reasons: it is well-defined even under partial failure (you just count), it weights by demand (an outage during peak traffic costs more budget than one at 3 a.m., which correctly reflects user impact), and it generalizes to non-serving systems — a batch pipeline measures fraction of records processed correctly, a storage system measures fraction of read/write operations that succeeded. This is exactly the good-events / valid-events SLI form used throughout Service Level Objectives and Choosing Good Service Level Indicators. The two metrics can diverge sharply: a service that drops 50% of requests for 12 minutes and is perfect otherwise has excellent time-based availability (it was “up” the whole day) but a request-based number that reflects the real user pain.

A refinement worth knowing is meaningful availability (Hauer et al., NSDI ‘20): even request-success-rate can flatter you if you measure at the server (“the load balancer returned 200”) rather than at the user (“the user actually received a working response”). Meaningful availability measures success from the user’s vantage point, counting the DNS failures, client-side errors, and network drops that server-side counters never see. The lesson: pick the measurement point closest to the user your target is supposed to protect.

Why Nines Past User Perception Are Wasted Spend

The reason SRE treats availability as a chosen number rather than a maximized one is the non-linear cost curve. The SRE Book states the economics directly: an incremental improvement in reliability can cost 100× more than the previous increment (Beyer et al. 2016, ch. 3). Moving from three nines to four nines does not cost 33% more; it typically requires new redundancy, multi-zone or multi-region architecture, automated failover, far stricter change management, and a paging discipline — a categorical increase in engineering investment for a 10× reduction in allowed downtime.

Against that cost sits a hard ceiling on perceptible benefit. Two independent effects cap how many nines the user can even see:

1. The delivery path is itself unreliable. A user reaching your service over the public internet is subject to packet loss, Wi-Fi drops, congested mobile networks, and their own device. Typical end-to-end internet packet loss is on the order of 0.01%–1%. If the network between you and the user already swallows your would-be fifth nine, delivering 99.999% at your server is invisible — the user experiences the worse of your availability and their connection’s. The SRE Workbook makes this argument explicitly: past roughly four nines, further server-side reliability for an internet-facing service is generally not perceptible (SRE Workbook, Implementing SLOs).

2. Clients are unreliable too. The software calling your service retries, caches, times out, and has its own bugs. A dependency that is 99.999% available, called by a client that is only 99.9% available, delivers a 99.9% experience — the client’s unreliability dominates.

The conclusion — one of the most-quoted lines in the field — is that 100% is the wrong reliability target for basically everything. The right target is the point where the user stops being able to tell the difference, minus a margin, and no tighter. Spending engineering effort to push availability above that point is not “being careful”; it is burning velocity on reliability the customer cannot perceive, which the error-budget model treats as a genuine anti-pattern (see Reliability Is a Feature Not an Afterthought and Error Budgets and the Error Budget Policy).

Chained Dependencies Multiply — the Calculus of Availability

The most important piece of availability arithmetic beyond the nines table is what happens when a service depends on other services. Availability of a serial chain multiplies: if your request must touch N critical dependencies to succeed, and each dependency is available with probability aᵢ, then — treating failures as independent — your achievable availability is at most the product:

A_service ≤ a₁ × a₂ × ... × a_N

Worked case: a service that fans out to five critical dependencies, each at 99.9%, cannot exceed 0.999⁵ = 0.99501, i.e. about 99.5% — it has lost half a nine purely to dependency composition, before adding a single bug of its own. Ten dependencies at 99.99% give 0.9999¹⁰ ≈ 0.999 = 99.9%. The unavailabilities add up (to first order, 1 − A ≈ Σ(1 − aᵢ)), so a chain is only as available as the sum of its dependencies’ failures.

This is the core of The Calculus of Service Availability (Treynor et al., ACM Queue 2017), which turns the multiplication into a design rule. If Service A targets 99.99% and splits its 0.01% error budget half to its own bugs and half across its critical dependencies, then with N critical dependencies each may consume only 1/N of that half — so each must fail roughly 10–20× less than A itself. Generalized, this is the “rule of the extra nine”: a critical dependency should be about one nine more reliable (≈ 10× more reliable) than the service that depends on it, so that its contribution to your unreliability is noise rather than the dominant term. A four-nines service wants five-nines critical dependencies.

When a dependency cannot offer the extra nine — which is common — you do not get to inherit its unreliability; you mitigate it. The paper’s remedies, all of which convert a critical dependency into a non-critical one, include caching its results so a brief outage is invisible, failing open (degrading to a safe default rather than an error when the dependency is down), and graceful degradation that drops the feature the dependency powers while keeping the core path alive (Treynor et al. 2017; see Load Shedding and Graceful Degradation and Fallback and Graceful Degradation Pattern). Each mitigation removes a term from the multiplication, which is why resilient architectures obsess over shrinking the set of hard dependencies on the critical request path.

Uncertain

Verify: the specific numeric framing of the “rule of the extra nine” and the 1/N error-budget split (each critical dependency gets one-Nth of the shared budget, so 5–10 dependencies must each fail 10–20× less). Reason: the primary PDF and CACM HTML of The Calculus of Service Availability returned 403/unparseable during this research, so these specifics rest on the paper’s abstract plus corroborating secondary summaries rather than a full read of the primary. The multiplication math itself (0.999⁵ ≈ 99.5%) is elementary and verified by direct computation. To resolve: read the full primary at sre.google PDF once accessible. #uncertain

Worked Example — Reading a Target Both Ways

Suppose you are asked to run an internal API at 99.95% over a rolling 30-day window.

As a time budget: (1 − 0.9995) × 43,200 min = 0.0005 × 43,200 = 21.6 minutes of allowed downtime in the window. That is your total budget for deploys-gone-wrong, dependency blips, and maintenance combined — about 43 seconds a day.

As a request budget: if the API serves 20 million requests over those 30 days, you may fail 0.0005 × 20,000,000 = 10,000 of them. This is the number that actually drives burn-rate alerting: you are not watching a clock, you are watching whether failed requests are accumulating faster than 10,000-per-30-days would allow (see Burn-Rate Alerting).

As a dependency constraint: if this API has three critical dependencies, the calculus says each should be materially better than 99.95% — ideally near 99.995% — or you must mitigate. Three dependencies at exactly 99.95% would cap you at 0.9995³ ≈ 99.85%, already below your own target before your code runs. This is why the first question in a production-readiness review is often “what are your critical dependencies and what are their SLOs?” (see Production Readiness Reviews).

The example shows the three faces of one number: a clock, a request count, and a composition constraint. Fluency in translating between them is what “reads the nines” actually means.

Availability versus Durability — a Common Confusion

Availability (can I reach my data now?) is distinct from durability (will my data still exist later?). They are quoted in the same “nines” style but mean different things and sit at wildly different levels. AWS S3, for instance, offers a 99.9% monthly availability SLA but is designed for 99.999999999% (eleven nines) durability. Eleven nines of durability is not “up 99.999999999% of the time” — it is a probabilistic statement that, of ten million objects, you would expect to lose roughly one every ten thousand years. The gap is intentional: a request you can retry (availability) is a recoverable annoyance, whereas a byte you have permanently lost (durability) is catastrophic, so storage systems buy far more nines of durability than of availability. Do not report a durability number as if it were an availability number, or vice versa — see Service Level Objectives for the SLI-by-system-type breakdown.

Time Window Matters — the “Nines” Are Meaningless Without One

A nines figure is incomplete until you attach a window. “99.9%” over a year permits 8.76 hours of downtime; “99.9%” over a day permits only 1.44 minutes. A single 20-minute outage is a comfortable non-event against an annual three-nines budget but blows a daily three-nines budget more than 13× over. This is why SLOs are stated as “99.9% over a rolling 28 days,” never bare percentages, and why rolling windows are preferred over calendar windows: a calendar-month budget resets on the 1st, tempting teams to burn it recklessly early or hoard it late, whereas a rolling window continuously ages out the oldest day so the budget updates smoothly (see Service Level Objectives §Tradeoffs). When someone quotes you a nines number with no window, they have told you almost nothing.

Production Notes

In real operations the nines target is the input to the whole error-budget machine: error budget = 1 − SLO, the budget is the downtime-or-failed-requests the team is allowed to spend, and burn-rate alerts fire when it is being consumed too fast (Burn-Rate Alerting, Multi-Window Multi-Burn-Rate Alerts). Public SLAs are deliberately set looser than the internal SLO — AWS S3’s 99.9% SLA sits below an internal availability that routinely exceeds 99.99% — so the internal alarm trips well before customer credits are owed (Service Level Agreements and Their Consequences). Achieving four nines and beyond forces architecture: multi-zone or multi-region redundancy, automated failover fast enough to fit inside a 52-minute annual budget, and change management strict enough that deploys rarely spend the budget (see Multi-Region Active-Active Architecture and Failure Domains and Blast Radius). And the governing judgment never changes: choose the fewest nines your users can perceive plus a margin, verify your critical dependencies can support it, and spend the rest of your engineering effort on features — because a nine the user cannot see is money set on fire.

See Also

• Service Level Objectives — the SLI/SLO/SLA framework and error budget that the availability number feeds
• The Four Golden Signals — availability is the errors/traffic signal expressed as a ratio; the measurement behind the nines
• Choosing Good Service Level Indicators — the good-events/valid-events form of request-based availability
• Error Budgets and the Error Budget Policy — 1 − SLO as a spendable budget; what happens when the nines run out
• Reliability Is a Feature Not an Afterthought — why the target is a product decision and the cost curve of nines
• Burn-Rate Alerting — alerting on how fast the availability budget is being consumed
• Redundancy and Failover Strategies — the architecture required once a target outruns human response time
• Multi-Region Active-Active Architecture — the pattern that enables four-plus nines
• Mean Time to Detect and Recover — why MTTR dominates time-based availability
• Site Reliability Engineering MOC — parent map