Base System
Redundancy Model (optional)
Model N identical components in series (all must work) or parallel (any one is enough).
How it works
Availability is the fraction of time a system is operational and able to do its job. This calculator derives it from two reliability inputs and translates the result into the language a board understands: a percentage, a number of "nines", and hours and minutes of downtime per year.
MTBF (Mean Time Between Failures, hours): the average operating time between one failure and the next. Higher MTBF means the system fails less often. MTTR (Mean Time To Repair, hours): the average time to detect, diagnose, and restore service after a failure. Lower MTTR means you recover faster. Availability improves when you either fail less often or recover faster.
Steady-state availability is the ratio of uptime to total time:
Downtime is the complement of availability across a full year of 8,760 hours (365 × 24). "Nines" is a compact log scale of the failure fraction:
Nines = −log10( 1 − A )
The optional redundancy model repeats one component N times. In series, every component must work, so availabilities multiply and reliability drops. In parallel, any one component is enough, so only the small unavailabilities multiply and reliability climbs sharply:
Worked example
A server fails on average every 2,000 hours (MTBF) and takes 4 hours to restore (MTTR). Then A = 2000 / (2000 + 4) = 0.9980040, or 99.80040% — about 2.70 nines and 17.49 hours (roughly 1,049 minutes) of downtime a year. Put two identical servers in parallel (N = 2) and combined availability becomes 1 − (1 − 0.9980040)² = 99.99960% — about 5.40 nines and only 2.1 minutes of annual downtime. Redundancy roughly squares the failure probability.
Benchmarks & reference points
The most useful anchor is the exact relationship between an availability target (the nines) and the downtime it permits per year. These figures are pure math from (1 − A) × 8760 h — use them to sanity-check any vendor SLA.
| Availability | Nines | Downtime / year | Typical framing |
|---|---|---|---|
| 90% | 1 nine | 36.5 days | Best-effort, non-critical |
| 99% | 2 nines | 3.65 days (87.6 h) | Basic business service |
| 99.9% | 3 nines | 8.76 h (525.6 min) | Standard cloud / SaaS SLA |
| 99.99% | 4 nines | 52.56 min | High-availability tier |
| 99.999% | 5 nines | 5.26 min | Carrier / mission-critical |
| 99.9999% | 6 nines | 31.5 sec | Fault-tolerant / real-time |
Related definitions you will pair this with, all standard and definitional rather than measured:
| Concept | Definition | Note |
|---|---|---|
| RTO | Recovery Time Objective | Max tolerable time to restore — conceptually the MTTR you commit to |
| RPO | Recovery Point Objective | Max tolerable data-loss window; independent of availability |
| SLE | AV × EF | Single Loss Expectancy = asset value × exposure factor |
| ALE | SLE × ARO | Annual Loss Expectancy = SLE × annual rate of occurrence |
Framing tiers are illustrative industry conventions, not guarantees; downtime figures are exact.
Using this in the boardroom
Boards do not fund abstractions like "three nines" — they respond to consequences. Convert availability into the numbers that carry weight: hours of outage per year, and the revenue, penalty, or reputational cost those hours represent. Pair this figure with an ALE estimate (SLE × ARO) so a resilience investment reads as reducing expected annual loss, not as a technical nicety. The gap between your current nines and your target nines is the size of the problem; the cost to close it is the ask.
Use the redundancy model to show the shape of the trade-off. Moving from a single node to a parallel pair often turns hours of annual downtime into minutes — compelling when the incremental hardware or region cost is modest against the avoided outage. Conversely, the series formula exposes hidden fragility: a service depending on five 99.9% components in a chain is only about 99.5% available end-to-end, a common reason "everything is three nines" still misses the SLA.
Key takeaway
Availability is a design output, not a wish. You buy nines by raising MTBF (better components, preventive maintenance) or cutting MTTR (monitoring, automation, redundancy). Present the number alongside its cost-of-downtime and the specific lever you are pulling.
Common pitfalls: quoting steady-state availability while ignoring RPO (data loss is invisible in this formula); assuming components fail independently when they share power, network, or a control plane; and confusing an SLA credit (a refund) with an SLA guarantee (actual uptime). Name these caveats before someone else does.
Frequently asked questions
What is a good availability target?
It depends on what the system does. Internal or best-effort tools often sit at 99% (two nines); customer-facing SaaS typically commits to 99.9%; payment, telecom, and safety-critical systems aim for 99.99% or higher. Each additional nine costs disproportionately more, so match the target to the actual cost of downtime rather than chasing nines for their own sake.
How is MTBF different from MTTR?
MTBF measures how often failures happen — the average uptime between incidents. MTTR measures how long each failure lasts — the average time to restore service. Availability rises when MTBF grows or MTTR shrinks, and you can improve either independently: reliability engineering raises MTBF, while monitoring and automation lower MTTR.
Why does redundancy improve availability so dramatically?
In a parallel configuration the system is down only when every component is down at once. Because each component is unavailable only a small fraction of the time, multiplying those fractions produces a far smaller number. Two 99.8% components in parallel reach roughly 99.9996% — the failure probability is effectively squared, provided the components fail independently.
Does higher availability mean less data loss?
No. Availability describes uptime, not data integrity. Data loss is governed by your RPO (Recovery Point Objective) and backup or replication strategy. A system can be highly available yet still lose the last few minutes of transactions in a failover, so evaluate RPO separately.
Can I use an SLA percentage instead of MTBF and MTTR?
Yes — if a vendor quotes 99.95%, read the equivalent annual downtime straight from the benchmarks table above. To model redundancy, treat that percentage as the per-component availability and apply the series or parallel formula. This tool works from MTBF/MTTR because those are the levers you actually control operationally.