SLA & Uptime Calculator

Why Downtime Budgets Shrink Fast as Systems Grow

A single service at 99.95% availability has a comfortable-looking downtime budget of about 4.4 hours a year. Chain five such services together in a synchronous critical path — where a request has to succeed through all five for the user-facing request to succeed — and the composite availability drops to roughly 99.75%, because the calculator multiplies each service's SLA together rather than averaging them. That's nearly an extra hour of yearly downtime that doesn't show up anywhere if you only inspect each dependency's SLA in isolation, and it's the reason microservice architectures with long synchronous call chains are structurally harder to keep reliable than a monolith with the same per-component reliability. The more services you add to a critical path, the faster the composite number falls away from any individual component's headline figure — this is exactly why architects work to minimize synchronous dependency depth and lean on caching, async processing, and graceful degradation instead of assuming reliability just adds up.

Redundant, parallel paths behave in the opposite direction, but only if modeled correctly. Two independent, active-active paths each at 99% availability don't combine to 198% (which is meaningless) or stay at 99% — they combine multiplicatively against their failure probability: 1 - (1-0.99)×(1-0.99) ≈ 99.99%. At scale, this is the entire economic argument for redundancy: doubling a mediocre component's reliability through parallel paths can outperform a single component that costs far more to make marginally more reliable on its own.

The Arithmetic Behind Every Figure on This Page

Converting a percentage into concrete downtime uses one formula: downtime = period × (1 - SLA% / 100). Applied to a 99.9% SLA over a 30-day month, that's 30 × 24 × 60 minutes × (1 - 0.999) = 43.2 minutes. The same formula scales to any period — a year, a week, a single day — simply by changing the period value, which is how the calculator produces the full table of downtime figures from one input. Composite SLA for services chained in series multiplies the individual figures together — composite = SLA_A × SLA_B × SLA_C — reflecting the fact that all components must be simultaneously operational for the composite system to be considered up. Parallel redundant paths use the complementary formula shown above, working from each path's failure probability rather than its uptime, because failure probabilities (not availability percentages) are what combine multiplicatively when paths are truly independent.

Where Uptime Math Bumps Into Security Commitments

SLA calculations intersect with security in a way that's easy to overlook: most vendor and internal SLAs define "downtime" purely in terms of service unavailability, without addressing whether a security incident that degrades functionality — a DDoS attack causing severe latency without full unavailability, or a service that's technically "up" but returning errors due to a security control blocking traffic — counts against the SLA at all. Contract language here matters as much as the arithmetic: a well-written SLA specifies whether a mitigated attack that only slows response times counts as a breach, and whether time spent in incident response for a security event is excluded the same way scheduled maintenance typically is. Teams that only run the numbers on "planned" outages and never model a security-incident scenario often discover, mid-incident, that their contractual and internal downtime definitions don't actually agree on what counts.

The Quarter a Single Dependency Ate the Whole Error Budget

A generic, illustrative case worth internalizing: a platform team commits to a 99.9% external SLA and sets an internal SLO of 99.95%, giving themselves what looks like a healthy safety margin. Partway through a quarter, they discover that a single third-party authentication provider they depend on synchronously — used for every login — has its own SLA of only 99.5%, far looser than anything else in their stack. Because that dependency sits in the critical path for every request, the team's actual composite availability was never going to reach 99.95% no matter how reliable their own code was; the third-party dependency alone consumed more error budget than the entire internal target allowed. The fix wasn't better code — it was moving authentication to an async, cacheable check with a fallback path, so a single external SLA no longer capped the ceiling of the whole system's composite availability.

Frequently Asked Questions