Availability (Nines) Calculator

Availability is the fraction of time a system can serve requests, and an end-to-end number is never better than the chain of things a request must pass through. This calculator composes your dependencies the way a request experiences them: every row is required, and each row can have redundant copies that cover for one another.

What it computes

Each dependency has an availability a (entered as a percentage) and a redundancy count k, the number of identical copies in parallel where any one is enough. The model is two rules applied in order:

effective_i  = 1 − (1 − a_i)^k_i          parallel copies
A            = effective_1 × effective_2 × …   series chain
nines        = −log₁₀(1 − A)
downtime/yr  = (1 − A) × 525,600 minutes   365 days
downtime/mo  = (1 − A) × 43,200 minutes    30 days

Redundancy works on unavailability: a component with k copies is down only when all k are down together. The chain works on availability: the request succeeds only if every row is up. The nines figure is fractional, so 99.95% reads as 3.3 nines rather than being rounded to three. Durations are printed in seconds, minutes, hours or days, whichever fits.

A worked example

The default architecture has three rows:

1. The app tier’s two copies turn 0.1% unavailability into 0.0001%. The effective column rounds to three decimals, so it displays this row as 100.000%.
2. Chain: 0.9999 × 0.999999 × 0.9995 = 0.999399, shown as 99.9399%.
3. Unavailability is 0.000601, so nines = −log₁₀(0.000601) = 3.2.
4. Downtime: 0.000601 × 525,600 = 316 minutes, shown as 5.3 hr per year, and 0.000601 × 43,200 = 26 minutes, shown as 26.0 min per month.

Set the app service back to one copy and the total falls to 99.8401%: 14.0 hours a year and 1.2 hours a month. One redundant tier saves almost nine hours of annual downtime. In the default setup, the database at 99.95% with a single copy is the largest remaining source: 0.0005 of the 0.0006 total unavailability.

Assumptions and limits

• Independent failures. The redundancy formula assumes copies never fail for the same reason. Shared zones, configuration, deploys and dependencies all break that, so the result is an upper bound.
• Instant, perfect failover. A copy covers for a failed one immediately and without errors. Real health checks and failover take seconds to minutes, and that time counts as downtime.
• Strict series. Every row is required for every request. Optional dependencies, caches with a fallback and graceful degradation are not modeled, which makes the tool pessimistic for systems built to degrade.
• Averages, not incidents. 5.3 hours a year could be one bad afternoon or many short blips. The model says nothing about how downtime is distributed.
• Fixed calendar. Monthly downtime uses 30 days; a calendar-month SLA over 31 days allows about 3% more.

How to use the result

Use the end-to-end figure to check whether a target is plausible before you promise it, and the effective column to decide where to invest.

• Your SLA must sit below the chain. If the composed figure is 99.94%, promising 99.95% to customers leaves no margin for deploys, failover time or correlated failures.
• Fix the weakest row first. The row with the lowest effective availability contributes the most downtime. A second copy there usually buys more than polishing an already strong component.
• Remove before you replicate. Every required dependency multiplies the total down. Taking one off the critical path, or making it optional, can beat adding redundancy everywhere.
• Turn the target into a budget. Monthly downtime is the error budget an SLO gives you; 26 minutes a month is roughly the room left for incidents and risky changes.

When to use it, and when not

Use it at design time, before anything is built: to check that a promised SLA is reachable from the parts you plan to use, to compare “add a replica” with “drop a dependency”, and to explain to a stakeholder why five 99.9% services cannot give a 99.99% product. It also helps when a vendor quotes one number and you need to see what that number does to your total.

It is the wrong tool once the system runs. Measured availability from request logs beats any composed estimate, because it already includes failover time, bad deploys and correlated outages. It also fits poorly where requests can succeed partly, such as a page that renders without recommendations, and for quorum systems, where a majority of copies must be up rather than any one.

Trade-offs and limits

The redundancy formula is only as good as its independence assumption. A common way to relax it is to say a share β of each copy’s failures hits every copy at once: a shared config push, a region outage, a bad release. Then unavailability is β × u + ((1 − β) × u)². For two copies of a 99.9% service:

Just 10% common-mode failure takes the pair from six nines to four. Failover time is the other gap. The formula says the pair is down 0.53 minutes a year. If each copy fails 10 times a year and every failover takes 60 seconds of errors (an illustrative figure), that adds 20 minutes, almost 40 times what the formula predicts. The real figure for the pair is then nearer 99.996%.

Quorums need their own formula. A three-node cluster that needs two nodes up has availability 3a² − 2a³. At 99.9% per node that is 99.9997%, about 1.6 minutes a year, not the nine nines that “any one of three” would claim.

Common mistakes

• Treating an SLA as an availability. A vendor SLA is a refund promise. It says what you get back when the vendor misses, not how often it misses. Use measured history where you can.
• Replicating the wrong row. In the default chain a third app copy moves the total from 99.9399% to 99.9400%. A second database copy moves it to 99.9899%. Spend redundancy on the weakest row.
• Counting optional dependencies in series. A cache with a fallback to the database, or a widget that can be hidden, does not take the request down. Leaving it in the chain makes the estimate too low and pushes you to harden the wrong thing.
• Forgetting the hidden rows. DNS, certificates, the auth provider, the config store and the deploy pipeline are all in the request path, or can take it out. A chain that lists only your own services is optimistic.
• Copies that share a fate. Two replicas in one zone, behind one switch, fed by one deploy, fail together. Without spreading them, the tool’s redundancy gain is mostly fiction.

Check yourself