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.
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.