Why availability combines rather than averages
Availability is the probability that a component is working when you ask it to. Combining components is therefore probability arithmetic, and the two basic structures pull in opposite directions.
In a series arrangement every block must work — a load balancer, then an application tier, then a database, then the storage under it. The probability that all of them are up at once is the product of their individual probabilities. Since every factor is at most 1, the product can only fall. Four dependencies at 99.99% give 0.9999⁴ = 99.96%, which is four times the downtime of any single one. This is the reason a service cannot promise an SLA tighter than the product of everything it depends on, and the reason removing a dependency from the request path is one of the highest-leverage reliability changes available.
In a parallel arrangement any one block is enough. The system is down only when everything is down simultaneously, so you multiply the unavailabilities: two units at 99% each give 1 − 0.01 × 0.01 = 99.99%. Two nines become four. Adding a third gives six. Redundancy is multiplicative in exactly the way chaining is, but in the direction you want.
A k-of-n cluster sits between them. Three replicas where any two constitute a quorum, or five web servers where four are needed to carry peak traffic. Because each unit is independently up or down, the number healthy follows a binomial distribution, and the availability is the probability that at least k of them are up. Series is the special case k = n; simple parallel is the special case k = 1.
The diagram this arithmetic describes is a reliability block diagram, standardised in IEC 61078. It is worth drawing on paper before you enter anything here, because most modelling errors are structural — a block that is really in series drawn in parallel — rather than numerical.
The three formulas and what each assumes
Series. A = A₁ × A₂ × … × Aₙ. When all the values are close to 1, a useful shortcut is that the unavailabilities simply add: a 99.9% component and a 99.99% component give roughly 0.001 + 0.0001 = 0.0011 unavailable, or 99.89%. The exact answer is 99.890001%, so the approximation is good to a part in ten thousand and is worth carrying in your head.
Parallel. A = 1 − (1 − A₁)(1 − A₂)…. Here the unavailabilities multiply, which is why each added unit buys roughly another factor of the unavailability. Going from one 99% unit to two takes you from 0.01 unavailable to 0.0001 — a hundredfold improvement from one extra machine. Going from two to three takes you to 0.000001. The returns are enormous on paper and are almost never realised in full, for the reason set out in the warning below.
k-of-n. A = Σ C(n,x) aˣ (1−a)ⁿ⁻ˣ summed from x = k to n. Each term is the binomial probability of exactly x units being healthy, and you add up every outcome that satisfies the quorum. For 2-of-3 at a = 0.9 that is C(3,2)(0.81)(0.1) + C(3,3)(0.729) = 0.243 + 0.729 = 0.972. Note what that tells you: three units where you need two is better than one unit (0.9) but worse than three units where you need one (0.999). The quorum requirement gives back part of what the redundancy bought.
Nines are just a logarithm. −log₁₀(1 − A) turns 0.001 unavailable into 3 and 0.0001 into 4. The scale is useful because each additional nine is a tenfold reduction in downtime and, empirically, close to an order of magnitude more expensive to deliver. It also makes non-round targets legible: 99.95% is 3.3 nines, which correctly reads as one third of the way from three to four.
Worked example: a three-tier request path, then adding redundancy
A request passes through a managed load balancer contracted at 99.95%, an application tier measured at 99.99%, and a single database instance measured at 99.9%. All three must work.
- Convert to decimals. 0.9995, 0.9999, 0.999.
- Multiply. 0.9995 × 0.9999 = 0.99940005. Then 0.99940005 × 0.999 = 0.99840064995.
- Read it as a percentage. 99.840065% — worse than every component in the chain, as a series arrangement always must be.
- Unavailability. 1 − 0.99840064995 = 0.00159935.
- Downtime per year. 0.00159935 × 525,600 = 840.6 minutes, or about 14 hours.
- Nines. −log₁₀(0.00159935) = 2.80. The chain does not even reach three nines.
Now find the leverage. The database contributes 0.001 of the 0.00159935 total unavailability, which is 62.5% of it. Improving the load balancer from 99.95% to 99.99% gives 0.9999 × 0.9999 × 0.999 = 0.99880021, so 99.880021% and 0.00119979 × 525,600 = 630.6 minutes a year — a saving of 210 minutes. Replacing the single database with a two-node cluster at 99.9% each takes that block from 0.001 unavailable to 0.001 × 0.001 = 0.000001, and the chain to 0.99940005 × 0.999999 = 0.99939905, so 99.939905% and 0.00060095 × 525,600 = 315.9 minutes a year. That single change removes 525 of the original 840.6 minutes.
The lesson generalises. In a series chain, the component with the lowest availability contributes the largest share of unavailability, so it is where the first improvement belongs — and duplicating a block is usually a bigger step than incrementally improving one.
How to read the result without over-trusting it
Convert the percentage into minutes before you form an opinion. Percentages near 100 are hard to feel: 99.9% and 99.99% look almost identical and differ by eight hours a year. The downtime table this calculator produces is the honest presentation of the same number.
Then check the assumption that does the most work: independence. Every parallel and k-of-n result assumes that units fail for unrelated reasons. Two servers in the same rack share a power distribution unit and a top-of-rack switch. Two availability zones share a region's control plane. Two replicas run the same software, so a defect triggered by a particular input takes both down at the same instant. A useful discipline is to compute the idealised figure, then ask what fraction of failures are genuinely independent; if only 90% are, the two-node cluster in the example above is nearer 99.99% than 99.9999%, because the correlated 10% never benefits from redundancy at all.
Failover is the second assumption. The parallel formula credits you with instant, always-successful switchover. In practice detection takes time, failover sometimes fails, and a fraction of in-flight requests are lost even when it works. If your failover takes 90 seconds and fires four times a year, that is six minutes of downtime that no amount of redundancy removes. Add it to the modelled figure rather than pretending it away.
Finally, remember that these numbers are long-run averages spread evenly, while real outages clump. A design that meets 99.95% over a year can still breach a monthly SLA in the month the outage lands. If your contract measures monthly, model monthly. The uptime and SLA downtime calculator converts between the two, and the SLO error budget calculator turns the target into an allowance you can track through the window.
Availability, nines and downtime
| Availability | Nines | Per year | Per 30-day month | Per week |
|---|---|---|---|---|
| 90% | 1 | 36.5 days | 72 hours | 16.8 hours |
| 99% | 2 | 3.65 days | 7.2 hours | 1.68 hours |
| 99.9% | 3 | 8.76 hours | 43.2 min | 10.08 min |
| 99.95% | 3.3 | 4.38 hours | 21.6 min | 5.04 min |
| 99.99% | 4 | 52.56 min | 4.32 min | 1.01 min |
| 99.999% | 5 | 5.26 min | 25.9 s | 6.05 s |
Every additional nine divides the downtime by ten. The step from 99.9% to 99.99% removes about eight hours a year; the step from 99.99% to 99.999% removes about 47 minutes, and usually costs considerably more.
Independence is the assumption that fails first
Two units at 99.9% in parallel compute to 99.9999% — thirty-two seconds of downtime a year. No real pair of servers achieves that, and the gap is not a rounding error. It is correlated failure: shared power, shared cooling, shared network, shared configuration, shared software, shared operator. A change pushed to both replicas at once is a single point of failure wearing a redundant costume.
Model it explicitly rather than hoping. Split the unavailability into an independent part and a common part, apply the parallel formula only to the independent part, and add the common part back. If 10% of a component's failures are common-mode, a redundant pair cannot do better than 10% of the single-unit unavailability, no matter how many units you add. That ceiling, not the binomial arithmetic, is what usually determines a real system's availability.
Modelling mistakes to avoid
- Drawing an optional dependency in series. If the request still succeeds when the recommendation service is down, that service is not in the request path and must not be multiplied in. Chaining things that only degrade the experience is the most common way a model comes out far too pessimistic.
- Using a vendor SLA as a measured availability. An SLA is the level below which credits become payable, not an expectation. Providers usually run well above it. Use your own monitoring where you have it, and treat the SLA as a floor.
- Ignoring the failover time in a parallel group. Detection plus switchover is downtime. Add it as a separate term rather than letting the formula credit you with an instant transition.
- Modelling planned maintenance as availability. Many SLAs exclude scheduled windows. If yours does, decide whether your users make the same distinction — they generally do not.
- Forgetting that a k-of-n cluster degrades before it fails. Losing one of three units when two are needed leaves you with no margin. The availability figure is unchanged; your risk is not.
- Reading nines as a linear scale. Moving from two nines to three is a tenfold change, and so is three to four. The cost of each step is not equal, and the benefit of each step is a tenfold reduction in downtime.
- Averaging component availabilities. Availability never averages. Series multiplies, parallel multiplies the complement. An arithmetic mean of the inputs is always wrong and usually flattering.
Key terms
- Reliability block diagram
- A diagram showing which components must work for the system to work. Blocks in series all have to function; blocks in parallel provide alternative paths. Standardised in IEC 61078.
- Common-mode failure
- A single cause that takes out several supposedly independent units at the same time — a shared power feed, a bad configuration push, a defect in software that all replicas run. It is what makes real redundancy fall short of calculated redundancy.
- k-of-n
- An arrangement in which any k of n identical units keep the service running. Quorum-based consensus systems are k-of-n with k = ⌊n/2⌋ + 1; capacity clusters are k-of-n with k set by peak load.
- Nines
- A logarithmic shorthand for availability: −log10 of the unavailability. Each additional nine divides annual downtime by ten.
- Composite SLA
- The end-to-end availability implied by chaining the SLAs of every service in a request path. It is always at most the lowest individual SLA in the chain.
Where this fits with the other reliability tools
Availability arithmetic tells you what a design can deliver. Three other numbers tell you whether that is enough and what it is worth.
The first is mean time between failures and mean time to repair, which produce availability from physical behaviour rather than from a contracted percentage: availability is MTBF divided by MTBF plus MTTR. If you know a component fails roughly twice a year and takes four hours to recover, you can derive its availability with the MTBF and MTTR availability calculator and feed the result into this one. That route also makes the cheapest lever obvious: halving repair time improves availability just as much as doubling time between failures, and is usually far less expensive.
The second is money. An availability improvement is worth what it avoids, and the IT downtime cost calculator converts the minutes saved here into an annual figure you can set against the cost of the extra hardware or the extra region.
The third is data. Availability says nothing about how much work an outage destroys, which is the recovery point objective. A design can be highly available and still lose an hour of writes when a replica is promoted; the RPO and RTO data-loss calculator quantifies that separately, and any serious design decision needs both numbers on the table.