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.

Security Commitments Add a Wrinkle to Uptime Math

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.

How One Synchronous Dependency Can Cap Your Whole Error Budget

An internal SLO stricter than the external SLA looks like a safety margin on paper, but that margin only holds if every dependency in the critical path is at least as reliable as the target implies. A synchronous dependency with a looser SLA than the rest of the stack — a third-party authentication provider, a payment gateway, a shared internal service used on every request — puts a hard ceiling on the composite availability of anything that depends on it, no matter how reliable the rest of the code is; the multiplicative math above means the weakest synchronous link, not the average, determines how much of the error budget is actually available. This is easy to miss because most teams monitor their own service's reliability closely and treat a third party's SLA as a fixed, background constant rather than an input to their own composite-availability calculation — the dependency's SLA doesn't need to change for it to become the dominant term in the equation; it only needs to sit on the synchronous critical path in the first place. The structural fix isn't improving the dependency's own reliability, which is usually outside your control anyway — it's removing it from the synchronous path entirely: moving a check to an async, cacheable flow with a fallback, or accepting degraded functionality instead of a hard failure when that dependency is slow or unavailable, so its SLA no longer caps the ceiling of the whole system's composite availability.

Frequently Asked Questions