Uptime / SLA Calculator

Converts an uptime percentage into actual allowable downtime — per day, week, month, year — because "99.9% uptime" doesn't mean anything concrete until you translate it into minutes you can actually plan around.

The nines, translated into real numbers

• 99% (two nines) — 3.65 days of downtime a year — not acceptable for most business systems, though it's often what a naive SLA defaults to
• 99.9% (three nines) — 8.76 hours a year — a common baseline SMB target
• 99.95% — 4.38 hours a year — roughly what major cloud providers commit to
• 99.99% (four nines) — 52.6 minutes a year — enterprise-grade, and it genuinely requires redundant infrastructure to hit consistently, not just a promise on paper
• 99.999% (five nines) — 5.26 minutes a year — telco-grade, needing active-active architecture with automated failover as a baseline, not an aspiration

What it actually takes to get there

Every extra nine means removing another single point of failure: redundant servers in active-active or active-passive configuration, redundant network paths with automatic failover, UPS and generator-backed power, database clustering with synchronous replication, load balancers doing real health checks, and — for the highest tiers — multi-region deployment purely for disaster recovery. None of it is optional if the SLA is going to hold up under an actual failure rather than just look good on a slide.

Why the small percentage difference is a bigger deal than it looks

99.9% sounds close enough to 100% that people gloss over it, but it still permits 43.8 minutes of downtime a month. For a business doing £10,000/hour in sales, that's roughly £7,300 a month in revenue at risk purely from the downtime the SLA already allows for, before anything actually goes wrong. Work out the real cost of downtime before agreeing to an SLA number, and be honest about whether the infrastructure behind it can actually deliver what's being promised — a number on a contract doesn't make the redundancy exist.

Planned counts too

SLA budgets have to include planned maintenance, not just unplanned outages — patching, upgrades, hardware swaps all eat into the same downtime allowance. Blue-green deployments, rolling updates and canary releases let you ship changes without burning any of that budget, keeping it available for the failures you didn't see coming.