Why nines get exponentially expensive
Availability is quoted in nines because the interesting quantity is not the percentage but its complement. At 99% you are down 5,256 minutes a year; at 99.9%, 525.6; at 99.99%, 52.56. Each nine removes exactly 90% of what the previous one left, which means the benefit of each step is ten times smaller than the step before it.
The cost moves the other way, and for a reason that is structural rather than accidental. You fix your failure modes in order of how cheap they are to fix. The first nine comes from restarting a crashed process automatically. The second comes from running two of everything in different zones. The third comes from removing the shared database, the shared deploy pipeline and the shared control plane. The fourth comes from removing the region, the vendor and the human — and by then you are paying for change-management discipline that slows every release, which is a cost that never appears in an infrastructure budget.
Put a shrinking benefit and a growing cost on the same axis and there is necessarily a crossing point. Above it, another nine costs more than the downtime it removes. This calculator finds that point at your numbers rather than at a rule of thumb, and it makes the cost model explicit: you supply the price of the first step and the multiplier that applies to each one after it, so the assumption is yours and visible rather than baked in.
What it will not do is tell you that five nines is silly. For some services it is correct — a payments authorisation path, an emergency dispatch system, a control plane other services depend on. The arithmetic simply says what that decision costs, so it can be made deliberately.
The three pieces of the calculation
Downtime. A year is 525,600 minutes, so downtime is 525,600 × (1 − availability). This is unambiguous, and it is the only part of the calculation with no assumptions in it. Dividing by your incident count gives the mean time to recover the target implies, which is often a more useful way to test whether a target is realistic: 99.99% with ten incidents a year means every incident must be resolved in an average of 5.26 minutes, including detection.
The value of removed downtime. Revenue per hour multiplied by the share you never recover. That second factor matters more than people expect. A retail checkout outage at midday loses most of its revenue permanently; a business tool that people return to in an hour loses very little. Setting the share to 100% is a defensible worst case, but it will make every step look worth buying.
The cost of a nine. The number of nines is −log₁₀(1 − A), which gives exactly 3 at 99.9% and 4 at 99.99%, and sensible fractional values in between: 99.95% is 3.30 nines. Cumulative cost above a 99% baseline is k·(mⁿ⁻² − 1)/(m − 1), a geometric series that reproduces k for the first step, k·m for the second and k·m² for the third. The cost of any move is the cumulative cost at the target minus the cumulative cost where you are now, which handles targets that are not round numbers of nines.
The optimal level is found by walking the ladder from 99% and taking each step while its own net benefit is positive. This is a marginal test, not a total one: a step is judged on the downtime it removes and the cost it adds, never on the cumulative position, because taking a losing step in the hope that a later one recovers the money is a mistake the geometry makes impossible — later steps are always smaller in benefit and larger in cost.
Worked example: is 99.99% worth it at $12,000 an hour?
Take the defaults: you achieve 99.9% today, you are considering 99.99%, you run ten incidents a year, the service carries $12,000 an hour of revenue, you lose 60% of it permanently, the first step costs $250,000 a year and each nine costs three times the last.
- Downtime now. 525,600 × (1 − 0.999) = 525.6 minutes a year, or 8.76 hours.
- Downtime at target. 525,600 × (1 − 0.9999) = 52.56 minutes a year.
- Downtime removed. 525.6 − 52.56 = 473.04 minutes = 7.884 hours.
- Effective loss rate. $12,000 × 60% = $7,200 per hour of downtime.
- Loss avoided. 7.884 × $7,200 = $56,764.80 a year.
- Cost of the step. The move is from 3 nines to 4 nines, the second step on the ladder, so it costs k × m = $250,000 × 3 = $750,000 a year.
- Net. $56,764.80 − $750,000 = −$693,235.20 a year.
- Check the step below. From 99% to 99.9% removes 5,256 − 525.6 = 4,730.4 minutes = 78.84 hours, worth 78.84 × $7,200 = $567,648, against a cost of $250,000 — a net of +$317,648.
So at these figures the first nine pays for itself more than twice over and the second does not come close. The optimal target is 99.9%, which is where you already are. That is a common and useful result: the honest answer to "should we go to four nines?" is frequently no, and the reason is arithmetic rather than ambition. Note also that the mean incident length the target implies is 52.56 ÷ 10 = 5.26 minutes — if your current mean time to recover is half an hour, the cost estimate above is the least of your problems.
Reading the result honestly
A negative net does not mean reliability work is not worth doing. It means this particular step, priced this way is not. Work that reduces incident frequency or shortens recovery without adding standing redundancy — better runbooks, faster rollback, progressive delivery — moves availability at a fraction of the multiplier assumed here, and is almost always the first thing to buy. The ladder in this model prices redundancy, which is the expensive way to buy nines.
Sanity-check the target against your incident data before costing it. An availability target is a statement about both how often you fail and how quickly you recover. If the implied mean incident length is shorter than your current time-to-detect, no amount of redundancy delivers the target, because the clock starts before anyone knows. The error budget calculator turns the same target into a monthly allowance you can actually manage against.
Watch the impact percentage. It scales the entire benefit side linearly, so halving it halves every loss-avoided figure and can flip the recommendation on its own. It is also the input with the least evidence behind it in most organisations. Measure it once from a real outage — compare that day's revenue against the same weekday's baseline — rather than assuming.
Contractual targets sit outside this arithmetic. If you have committed to 99.99% in a customer contract, the calculation tells you what that commitment costs, not whether to honour it. Compare that cost against the credits at risk in the SLA credit versus actual loss calculator; the credits are usually far smaller than the hardening cost, which is why availability commitments are made for commercial access rather than for their direct economics.
Allowed downtime at each availability level
| Availability | Nines | Per year | Per month | Per week |
|---|---|---|---|---|
| 99% | 2 | 3 d 15 h 36 m | 7 h 18 m | 1 h 40.8 m |
| 99.9% | 3 | 8 h 45.6 m | 43.8 m | 10.1 m |
| 99.95% | 3.30 | 4 h 22.8 m | 21.9 m | 5.0 m |
| 99.99% | 4 | 52.56 m | 4.38 m | 60.5 s |
| 99.999% | 5 | 5.26 m | 26.3 s | 6.0 s |
| 99.9999% | 6 | 31.5 s | 2.6 s | 0.6 s |
Read the weekly column when judging whether a target is achievable at all. At 99.99% a single ten-minute incident consumes ten weeks of allowance, which is why four nines is a deployment-practice problem long before it is a redundancy problem.
Where this model is wrong, and how wrong
- The cost multiplier is an assumption you supply. Nothing measures it for you. Anchor it by pricing two adjacent steps in your own estate and dividing; if you cannot, run the calculation at 2× and at 5× and see whether the recommendation changes.
- Downtime cost is treated as linear in duration. Real outages are not. Short ones often cost less than proportional and long ones far more, once churn, contractual penalties and reputational effects arrive.
- Availability does not decompose the way the ladder implies. A service with a 99.99% dependency cannot exceed 99.99% no matter what you spend on your own tier. Check your dependency chain before setting a target above your weakest hard dependency.
- Redundancy adds its own failure modes. Failover logic, split-brain, cross-region consistency and the operational complexity of a bigger estate all cause outages. Past a point, added redundancy can reduce measured availability, which no model with a monotonic cost curve can express.
- Planned maintenance is excluded from many published availability figures and included in others. Decide which convention you are using and apply it to both the current and the target figure, or the comparison is meaningless.
- The first step is anchored at 99%. If your estate is already well past that, the cumulative cost at your current level is a modelled figure rather than a measured one — but the difference between two levels, which is what the calculator reports, remains the quantity you care about.
Buy time-to-recover before you buy redundancy
Availability is the product of how often you break and how long you stay broken, and only the second is cheap to improve. Faster detection, one-click rollback, progressive delivery and a rehearsed on-call rotation shorten every incident you will ever have, at a cost that does not multiply by three for each nine. Price those first, remeasure, and then come back to this calculator with a new current-availability figure. The step you were about to buy may already have been delivered.
How this fits with the rest of the reliability budget
This calculator answers a strategic question: what availability level should we aim at. Three adjacent tools answer the operational ones. The uptime and downtime calculator converts any percentage into minutes for any window, which is the quickest way to check whether a proposed SLA is survivable. The error budget calculator turns the target into a monthly allowance and a burn rate, which is how the target gets managed day to day. And the incident response cost calculator prices a single outage across revenue, engineering time and displaced work — a useful cross-check, because if your measured per-incident cost is far from what this model implies, one of the two inputs needs revisiting.
Availability and disaster recovery are separate budgets solving separate problems. Nines are about the frequent, short failure; DR is about the rare, total one. Buying a multi-region active/active posture to raise ordinary availability is one of the most expensive ways to do it, and the backup and DR cost calculator prices that ladder on its own terms. Money spent in the wrong one of the two budgets buys very little in the other.
Finally, if the downtime figure you are protecting includes internal productivity loss rather than just revenue, the IT downtime cost calculator builds that side of the number properly, and feeding a better revenue-per-hour figure into this calculator will change the recommendation faster than any refinement of the cost model.
Key terms
- Nine
- One factor of ten in the unavailability. Formally −log₁₀(1 − A), so 99.9% is three nines and 99.95% is 3.30.
- Marginal analysis
- Judging each step by the benefit and cost of that step alone, rather than by the cumulative position. The correct test when benefits shrink and costs grow.
- Impact share
- The fraction of revenue lost during an outage that never returns. Distinguishes deferred purchases from destroyed ones.
- Mean time to recover
- Average incident duration. Availability targets imply a maximum MTTR once you fix the incident count, which is often the more testable form of the target.