Availability arithmetic: what 99.9, 99.99 and 99.995 mean when components are chained

About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.

Over a 365-day year, 99.9% allows 8.76 hours of downtime, 99.99% allows 52.56 minutes and 99.995% allows 26.28 minutes. In a 30-day month those budgets are 43.2, 4.32 and 2.16 minutes. For independent hard dependencies, component availabilities multiply, so six components that look healthy on their own can deliver about 99.86% together. Redundancy can repair that, but only to the extent that the redundant parts fail independently, and they rarely do.

The practical consequence: do not quote a component's percentage as the service's percentage. Budget the whole request path, count what the redundant sides share, and then measure the result from where the user stands.

The alert rules below come from Google's published SRE material and were not run in a lab. All figures in our own worked examples, including percentages, failure counts and durations, are invented for the arithmetic.

Interpretations are editorial; no lab testing was performed.

Why it matters

A percentage without a scope says very little. It needs a definition of "working", a measurement point, a time window and a list of what is excluded.

The window matters as much as the number. One 30-minute outage in a 30-day month still meets 99.9% for that month, but breaks 99.95%. A single five-minute event breaks a monthly 99.99% commitment.

The last row also tests a recovery plan against an availability target. NIST SP 800-34 Rev. 1 (May 2010, updated November 2010) defines the recovery time objective (RTO) as the longest a resource can stay unavailable before the impact becomes unacceptable. An actual four-hour outage breaches a 99.99% annual target: it is about 4.6 times that year's 52.56-minute budget. Budgets cannot be borrowed from future years.

How it works

The downtime budget

AWS defines availability as uptime divided by the total time measured. The budget is therefore (1 - A) x period.

Google's availability table states that it assumes no planned downtime, and that assumption matters. AWS advises against excluding planned maintenance from total time, because users are likely to want the service during those periods.

Frequency multiplied by duration

AWS gives the estimate as MTBF divided by (MTBF + MTTR), where MTBF is the mean time between failures and MTTR the mean time to repair. Its example is 150 days between failures and one hour to recover, giving 99.97%.

For planning it is often easier to think in failures a year. Availability is approximately 1 - (failures x hours per failure / 8760).

Four incidents a year at 99.99% leaves about 13 minutes for each one, and 6.6 minutes at 99.995%. AWS counts detection time inside MTTR. An incident that waits for someone to be paged, sign in and decide is unlikely to fit. In our view, targets at this level need most recovery to be automated, which has costs of its own, covered under failover below.

Treat this as a planning tool rather than a forecast: AWS notes that both values are averages with real variance around them.

Serial chains: unavailability adds up

A hard dependency is something the workload cannot function without. A soft dependency can be unavailable for a while without the failure being noticed or mattering. Only hard dependencies go into the product.

AWS's example is three independent 99.99% systems giving 99.97%.

Here is an invented request path in which every part is a hard dependency.

The total is about 735 minutes, or 12.3 hours a year, and about 60 minutes in a 30-day month. No single line looks alarming, yet the service misses 99.9%.

At these levels you can skip the multiplication. Add the unavailabilities: 0.01 + 0.01 + 0.05 + 0.01 + 0.05 + 0.01 = 0.14%, giving 99.86%. The shortcut also shows where the effort should go, because the two 0.05% terms account for more than 70% of the total.

Before using that sum, take the caveat. AWS says the product is a theoretical maximum that is likely to be only "a rough order of magnitude" and "by itself is likely not to be accurate or provide meaningful insight". A workload built on two or three 99.99% dependencies can still reach 99.99% or higher, because the input numbers are estimates and dependencies frequently beat their published figures. In our view its use is comparing designs and finding the largest term. Do not present it as a prediction.

With that limit in mind, run the sum backwards to set rough component targets. To deliver 99.99% through six equal hard dependencies, each needs about 99.9983%, which is 8.76 minutes a year. For 99.995% each needs about 99.9992%, or 4.38 minutes. AWS's general rule is to choose dependencies whose availability goals are equal to or greater than the workload's. Google's workbook makes the same point for a critical dependency of a high-value interaction.

Parallel components: failures must coincide

If either of two independent subsystems can carry the work, both must fail together for the service to fail. Multiply the unavailabilities instead of the availabilities: A = 1 - (1 - a1) x (1 - a2).

Two independent 99.9% components give 99.9999%, and two at 99% give 99.99%. For n subsystems with s spares, AWS gives the approximation A ≈ 1 - f x (1 - a)^(s + 1), where f is the number of ways s + 1 subsystems can be chosen from n.

The practical trap is capacity. A spare counts only if the survivors can carry the load. AWS's example is a workload needing 10 instances at peak. In one Availability Zone (AZ) the unit of failure is the whole AZ, so the sound layouts are 10 instances in each of two zones, or 5 in each of three.

Independence is the assumption that breaks

Google's SRE workbook addresses this directly. Two zones at 99.9% appear to give 99.9999%, but that reasoning assumes the two are wholly independent, which it says is almost never the case. They have common dependencies, common failure domains, shared fate and global control planes.

Reliability engineering has a standard way to express this. NASA's Probabilistic Risk Assessment Procedures Guide (second edition, December 2011, section 7.4 and equations 7-3 and 7-4) defines a common cause failure as more than one component failing or being unavailable because of a shared cause. Its beta-factor model splits each component's failure frequency into an independent part and a common-cause part, with beta (β) as the common-cause fraction. Common-cause events bypass the redundancy altogether.

Applied to unavailability U, a redundant pair becomes U_pair ≈ βU + ((1 - β)U)^2. NASA's equation is written for failure probabilities. Using it for steady-state unavailability is our simplification, and it assumes similar repair times for both kinds of event.

Here are two 99.9% units with different values of β. The values are illustrative and are not measurements.

With a 10% common-cause fraction, the pair delivers about four nines and not six. The βU term dominates almost immediately, so past a certain point better boxes buy little. Removing what the two sides share buys a lot.

Your own incident records can give an estimate. NASA's point estimate is β = 2n2 / (n1 + 2n2), where n1 counts independent failures and n2 counts common-cause failures. Eighteen single-side failures and one both-sides failure give 10%. With counts that small, read it as a rough indication only.

Walk through the shared list for each redundant pair. Typical candidates, in our judgement, are:

• a change applied to both sides at once, such as a firmware, patch or configuration push;
• one power feed, cooling plant, switch pair or storage fabric behind both sides;
• a control plane, identity service, certificate or DNS zone that both sides need;
• a load surge that follows a failover and overwhelms the survivor.

Now rerun the invented path. Make the application tier and the database two-sided at 99.95% per side, with β at 10%. Each pair becomes 99.99498%. The whole chain improves only to about 99.950%, or 263 minutes a year, because the four unpaired 99.99% items now dominate. Raising those four to 99.995% gives about 99.970%. Pairing the two largest terms was the right first step, and it still did not reach 99.99%.

Failover is downtime too

The parallel formula has no term for the switch itself. AWS notes that some failovers, such as promoting a database without built-in leader election, require downtime, cannot be immediately reversed and leave the workload without redundancy for a period, and concludes "it's important to have a human in the decision-making process". The same page warns that fail-fast mechanisms make a workload "very sensitive to transient errors". Four failovers a year at three minutes each cost 12 minutes. That is 23% of an annual 99.99% budget and 46% of a 99.995% budget.

That pulls against automating everything. Our reading: automate the failovers whose technology elects its own leader and can be reversed safely. Where a person must decide, that decision time will rarely fit a 99.99% budget, so either redesign that dependency or accept that it sets the limit of the service.

Turning hard dependencies into soft ones

The cheapest term to reduce is often the one that can leave the product. Google suggests caching, offline store-and-forward processing and graceful degradation when a component cannot reach the required level. AWS calls a related property static stability: systems preconfigured to tolerate failure do not need a control plane in order to recover.

What a published SLA really measures

An SLA, or service level agreement, is a contract with financial and legal consequences. Its definition of "down" is usually narrower than a user's. Microsoft states that SLAs do not guarantee an offering as a whole and that you should understand the coverage behind the percentage. Two current compute SLAs show why.

If one of two zones is lost and the other stays reachable, neither multi-zone definition above is met, so that is not downtime under the SLA. Half your capacity may still be gone. A slow or error-returning application with working network connectivity is outside both definitions. A burst of sub-minute drops does not count under Google's definition.

These are our readings of the published wording, and the contract text governs. A credit is also a percentage of a compute bill, which bears no fixed relationship to what an outage costs you.

The same questions apply when comparing any provider: what is measured, from where, over which window, what is excluded, how planned maintenance is treated, and what the remedy is.

Measuring what you delivered

AWS describes three empirical measures, and each has a blind spot.

Server-side success rate. Valid requests succeeded divided by valid requests received. If clients cannot reach the service, the failed attempts are never recorded.

Client-side success rate. Usually measured with canaries, which are probes that simulate customer traffic.

Annual downtime. You define an outage condition first, then add up the periods that meet it. AWS's example is 27 five-minute periods below 95%: 135 minutes, or 99.97%.

A response that arrives after the client's timeout looks like a success on the server, which is why AWS suggests treating a latency target breach as downtime. NIST's glossary definition of availability likewise requires access to be timely as well as reliable.

On windows, Google recommends a four-week rolling window as a good general-purpose interval, because a whole number of weeks always contains the same number of weekends.

To be told while there is still budget left, alert on burn rate, meaning how fast the budget is being consumed. Google's recommended starting point (its Table 5-8) for a 99.9% SLO over 30 days pages when 2% of the budget goes in an hour or 5% in six hours, and raises a ticket for 10% over three days. Each rule also has a shorter window, so that the alert stops soon after the problem does.

expr: (
  job:slo_errors_per_request:ratio_rate1h{job="myjob"} > (14.4*0.001)
  and
  job:slo_errors_per_request:ratio_rate5m{job="myjob"} > (14.4*0.001)
) or (
  job:slo_errors_per_request:ratio_rate6h{job="myjob"} > (6*0.001)
  and
  job:slo_errors_per_request:ratio_rate30m{job="myjob"} > (6*0.001)
)
severity: page

expr: (
  job:slo_errors_per_request:ratio_rate3d{job="myjob"} > 0.001
  and
  job:slo_errors_per_request:ratio_rate6h{job="myjob"} > 0.001
)
severity: ticket

The 0.001 is the error budget for 99.9%. Substituting 0.0001 or 0.00005 changes the arithmetic for 99.99% and 99.995%, but not what alerting can do there. Google's example is 99.999%, where a total outage uses the monthly budget in 26 seconds, and it says the only defence at that level is a design that makes a 100% outage extremely unlikely. By the same arithmetic, a total outage spends a 99.995% monthly budget in 2.16 minutes, which detection and paging will consume most of. The recording rules are yours to define. Google warns that low-traffic services need different handling: at 10 requests an hour, one failure is a 10% error rate for that hour.

What to choose and why

These steps are our recommended method.

1. Name the user journey and define failure for it, including a latency limit.
2. List every hard dependency on that journey, including the DNS, identity, certificates and network paths that diagrams tend to leave out.
3. Collapse each redundant group into one number using a stated common-cause fraction. If you cannot defend a value, show a range such as 5% to 20%.
4. Add failover time as expected events multiplied by duration.
5. Add the unavailabilities and rank them. Work on the largest term first, or make it soft.
6. Publish the assumptions next to the result.
7. Measure from outside the service, then compare. Where measured results and the model disagree, trust the measurement and work out why.

As a rough guide to what each target demands, in our judgement:

We recommend an internal objective tighter than anything you promise, so that you hear about trouble before the contract is at risk. AWS's measurement example shows a 99.5% goal above a 99% SLA. This is our view and not a universal rule: Microsoft says the two "should be independently controlled", and its worked example has a 99.90% SLA that "exceeds the SLO target of 99.45%", set as a business decision.

Risks and limits

• The inputs are soft. Vendor percentages are commitments or estimates. They are not measurements of your deployment.
• Short windows prove little. At 99.995%, a whole year allows 26 minutes. A fully measured incident-free year establishes observed availability for that year. It does not establish the future failure probability or independence of redundant components.
• Availability is not recoverability. NIST treats the recovery point objective, or RPO, as a measure of tolerable data loss, separately from downtime. A service can meet its percentage and still lose data.
• More nines can make things worse. Google says that past a certain point, increasing reliability is worse for a service and its users. AWS adds that spares increase both cost and complexity.

Sources

Opened 2026-11-10.

• AWS: Availability and Beyond, Understanding availability
• AWS: Distributed system availability
• AWS: Availability with dependencies
• AWS: Availability with redundancy
• AWS: Reducing MTTR
• AWS: Measuring availability
• AWS Well-Architected: Availability
• AWS Fault Isolation Boundaries: Static stability
• Amazon Compute Service Level Agreement
• Google Compute Engine SLA
• Google SRE Book: Availability table
• Google SRE Book: Embracing risk
• Google SRE Workbook: Implementing SLOs
• Google SRE Workbook: Alerting on SLOs
• Microsoft Azure Well-Architected: Architecture strategies for defining reliability targets
• NASA/SP-2011-3421: Probabilistic Risk Assessment Procedures Guide, Second Edition
• NIST SP 800-34 Rev. 1: Contingency Planning Guide
• NIST CSRC Glossary: availability

This article was originally published on 10 November 2026.