Availability (Nines) Calculator
Chain dependencies in series and parallel and watch the combined availability — and the yearly downtime it implies — fall out. Unlike single-service "nines" calculators, this one models the dependency graph, so you see how one shaky component drags down the whole system.
Dependencies are composed in series (all required) — their availabilities multiply. Add redundancy to put copies in parallel and claw nines back.
What "nines" actually mean
Availability is the fraction of time a system is up, quoted in nines: 99.9% ("three nines") is ~8.8 hours of downtime a year; 99.99% is ~52 minutes; 99.999% is ~5 minutes. Each extra nine is roughly 10× harder and costlier — so choosing the right target matters as much as hitting it.
Series vs parallel
How you compose components changes the math:
- In series (a request must pass through every component — load balancer and app and database), availabilities multiply. Three 99.9% services in a row give ≈99.7% — worse than any single one. Dependencies are a tax on uptime.
- In parallel (redundant replicas where any one suffices), the unavailabilities multiply. Two 99% replicas fail only if both fail: 1 − (0.01 × 0.01) = 99.99%. Redundancy buys nines back.
The practical takeaway
A long dependency chain silently erodes your SLA; the cure is redundancy on the critical path and removing needless dependencies. Compose your architecture above and see the real end-to-end number — usually lower than teams expect.
How it works
- Series (all required): availabilities multiply — every dependency drags it down.
- Parallel (redundant): unavailabilities multiply — 1 − (1 − a)ⁿ.
- Downtime/year = (1 − availability) × 8,760 hours.
- Each additional nine is ~10× less downtime and far harder to reach.
Frequently asked questions
What do "nines" of availability mean?
Nines describe uptime as a percentage: three nines (99.9%) allows about 8.8 hours of downtime per year, four nines (99.99%) about 52 minutes, and five nines (99.999%) about 5 minutes. Each extra nine is roughly 10× harder and more expensive to achieve.
How does availability combine in series?
When a request must pass through several dependencies in series, their availabilities multiply: 0.999 × 0.999 × 0.999 ≈ 0.997. So adding more required dependencies always lowers overall availability — the chain is weaker than its weakest link.
How does redundancy (parallel) improve availability?
With redundant components in parallel, the system is down only if all of them are down, so unavailability multiplies: combined availability = 1 − (1 − a)ⁿ. Two 99% replicas in parallel give 99.99% — this is why redundancy is the main tool for adding nines.
Why model the dependency graph instead of one number?
Real systems are chains of dependencies (load balancer → service → database → cache), each with its own SLA. The end-to-end availability is the composition of all of them, so a single-service calculator overstates your real uptime. This tool composes series and parallel groups for you.