Calculate SLA uptime percentages and error budgets. Convert between nines of availability and allowed downtime.
Converting 99.9% into 43 minutes and 12 seconds a month is arithmetic, and it is where most uptime calculators stop. It answers a contract question, not an engineering one. The question an architect actually faces is what availability the whole system delivers once every dependency in the request path is counted.
Components in series multiply: A_total = A1 x A2 x ... x An. Five components at 99.9% each give 99.5%, not 99.9% - roughly 44 hours a year instead of 8.75. The composite is always worse than the weakest link, and adding any dependency, however reliable, can only push it down. The Architecture tab makes this concrete: add a load balancer, application servers, a database, DNS and a third-party API, and watch the number fall below every individual component in the list.
Independent replicas combine as A_total = 1 - (1 - A)^n, so two 99.9% servers reach 99.9999% on paper. A cluster that needs k of n healthy nodes follows the binomial sum over the states with at least k survivors, which is the right model for a three-node Raft or etcd quorum.
Both formulas rest on the word independent, and that is where the money goes. Replicas share an availability zone, a power feed, a control plane, a deployment pipeline, a certificate authority and an on-call engineer. The correlation control splits each component's unavailability into an independent share and a common-cause share, then shows what is left of the benefit. At only 10% correlation, that same mirrored pair drops from 99.9999% to about 99.99% - roughly a hundred times more downtime, from a number that almost never appears in a design document.
The Monte Carlo tab simulates thousands of years of the composed architecture from per-component MTBF and MTTR, and reports the distribution of annual downtime: P50, P95, P99 and the probability of breaching a target SLA. The P99 year commonly carries several times the mean downtime. Two designs with identical mean availability can differ enormously in breach probability, because a system that fails often and recovers in minutes rides out a monthly SLA that a system with one long outage a year fails outright.
Service Level Agreements (SLAs) and Service Level Objectives (SLOs) define the expected reliability and performance of services in quantitative terms. An SLA is a contractual commitment (with financial penalties for breaches), while an SLO is an internal target that teams use to balance reliability investment against feature development.
Understanding the mathematics behind availability percentages, error budgets, and downtime calculations is essential for platform engineering, DevOps, SRE (Site Reliability Engineering), and service management.
| Availability | Annual Downtime | Monthly Downtime | Called |
|---|---|---|---|
| 99% | 3.65 days | 7.3 hours | "Two nines" |
| 99.9% | 8.77 hours | 43.8 minutes | "Three nines" |
| 99.95% | 4.38 hours | 21.9 minutes | Common SaaS SLA |
| 99.99% | 52.6 minutes | 4.38 minutes | "Four nines" |
| 99.999% | 5.26 minutes | 26.3 seconds | "Five nines" |
Error budget is the inverse of SLO — the amount of unreliability your service can tolerate before violating its objective:
Error Budget = 1 - SLO
With a 99.9% SLO, your error budget is 0.1% — approximately 43 minutes of downtime per month. When the error budget is consumed, teams should freeze deployments and focus on reliability.
| Metric | Definition | Example Target |
|---|---|---|
| Availability | Percentage of time the service is operational | 99.95% |
| Latency (p50) | Median response time | < 100ms |
| Latency (p99) | 99th percentile response time | < 500ms |
| Error rate | Percentage of requests that fail | < 0.1% |
| Throughput | Requests processed per second | > 10,000 rps |
A single availability percentage describes a component. Systems are made of components, and the way they compose is what decides your uptime.
Series composition destroys availability. If every component must work for a request to succeed, availabilities multiply:
A_total = A1 x A2 x ... x An
Six services at 99.95% compose to 99.7%, about 26 hours a year. No vendor SLA changes that. Only removing dependencies from the critical path - through caching, graceful degradation, or making a call optional - does. This is the most misunderstood fact in availability engineering, and it means the composite is always worse than the weakest link, never the average of the parts.
Redundancy multiplies unavailability instead. For n independent replicas where any one is sufficient:
A_total = 1 - (1 - A)^n
Two 99.9% instances reach 99.9999%; two 99.99% instances reach eight nines. These are the numbers that get quoted in design reviews, and they are almost never achieved.
Quorums follow the binomial sum. A cluster that needs k of n healthy nodes is neither series nor simple parallel:
A_total = SUM(j = k..n) C(n, j) x A^j x (1 - A)^(n - j)
A 2-of-3 etcd or Raft cluster tolerates exactly one failure, the same as a mirrored pair, but has three components that can fail. Choose it for consistency and split-brain avoidance, not for raw availability.
Where to spend. Because availability is MTBF / (MTBF + MTTR), halving MTTR improves it by exactly as much as doubling MTBF - and it is far cheaper. MTBF moves with better hardware, better software and less change, all slow and expensive. MTTR moves with faster detection, clear alerting, rehearsed rollback, a current runbook and an engineer who has the access to fix things. Most organisations sitting at three nines reach three and a half by shortening incidents rather than preventing them.
Two things separate a realistic availability model from an optimistic one: admitting that replicas fail together, and looking at the distribution rather than the average.
Independence is an assumption, not a property. Every redundancy formula carries the word independent. Real replicas share an availability zone, a power feed, a top-of-rack switch, a control plane, a deployment pipeline, a certificate authority and an on-call rotation. Model it with a beta factor: split each component's unavailability U = 1 - A into a common-cause share rho x U and an independent share u = (1 - rho) x U. The group is up if the common cause has not fired and at least k instances survive:
A_group = (1 - rho x U) x SUM(j = k..n) C(n, j) x (1 - u)^j x u^(n - j)
With rho = 0 this reduces to the textbook binomial; with rho = 1 it reduces to a single instance, because every copy fails together. The consequence is stark: the independent term falls off geometrically with n while the common-cause term does not fall off at all, so beyond two or three replicas availability is governed almost entirely by rho. Adding a fourth node to a cluster that shares one power feed and one config push buys nothing. Spending the same money on a second availability zone, a staged rollout, or separate certificate issuance buys a great deal.
The tail breaches the SLA, not the mean. Mean availability is an expectation over many years. Your contract is judged one month or one quarter at a time. Simulating per-component MTBF and MTTR across thousands of years shows the shape of the distribution, and the P99 year commonly carries three to five times the mean downtime.
The repair-time distribution matters as much as the failure rate here. Real incident durations are lognormal - most are resolved quickly, a few run all night because the failure was novel, the runbook was stale, or the escalation path took an hour. That right tail is where SLA breaches live. Two architectures with identical mean availability can have very different breach probabilities: many short outages are absorbed by a monthly allowance that one long outage destroys.
The practical order of operations follows directly. Count every dependency in the request path and compose them honestly. Shorten MTTR before chasing MTBF. Spend on decorrelation rather than on replica count. Then validate the design against the P95 and P99 year rather than the average one.
SLA (Service Level Agreement) is a contract with customers. SLO (Service Level Objective) is an internal target for service reliability. SLI (Service Level Indicator) is the actual measured metric like uptime or latency. SLIs inform whether you are meeting SLOs, which determine SLA compliance.
If every component must be working for a request to succeed, the components are in series and their availabilities multiply: A_total = A1 x A2 x ... x An. Four components at 99.9% give 0.999^4 = 99.6%, which is about 35 hours of downtime a year rather than 8.75. The composite is always lower than the worst individual component, so adding any dependency - an identity provider, a feature-flag service, a licence server - reduces the number even when that dependency is very reliable. Use the Architecture tab to build the chain and see the composite; the most valuable output is usually the dependency inventory itself, because teams routinely discover something in the request path that nobody had counted.
For n genuinely independent replicas where any one can serve traffic, the unavailabilities multiply: A_total = 1 - (1 - A)^n. Two 99.9% servers reach 99.9999%, and three reach nine nines on paper. For a quorum that needs k of n healthy nodes, use the binomial sum over every state with at least k survivors: A = SUM(j = k..n) C(n, j) x A^j x (1 - A)^(n - j). Note that 2-of-3 is not simply better than 1-of-2 for availability - both tolerate one failure, but the quorum has three components that can fail. Its advantages are consistency and split-brain avoidance. And all of these numbers assume independence, which is where they break down in practice.
Correlated - or common-cause - failure is anything that takes more than one replica out at the same time: a shared availability zone, a shared power feed or top-of-rack switch, a configuration push applied everywhere at once, an expired certificate from the same source, a poison-pill request that crashes every instance, or a dependency all the replicas share. The Architecture tab models it with a beta factor: a share rho of each component's unavailability is treated as a common cause hitting the whole group at once, and only the remaining (1 - rho) share behaves independently. Because the independent term shrinks geometrically with each replica while the common-cause term does not shrink at all, correlation dominates as soon as you add redundancy. At 10% correlation a mirrored 99.9% pair falls from 99.9999% to roughly 99.99%. Past two or three instances, only decorrelation moves the result - a fourth node behind one power feed and one deployment pipeline is theatre. Rough starting estimates: two VMs on one hypervisor 40-60%, two instances in one availability zone 15-30%, two zones in one region 5-15%, two regions with independent deploy pipelines 1-5%.
Because an SLA is breached by the tail, not the mean. Mean availability is an expectation across many years and says nothing about how downtime falls within any single year, which is what the contract judges. The Monte Carlo tab draws failures for each instance from an exponential process at rate 1/MTBF and repair durations from your chosen distribution, then measures the composed system across thousands of simulated years. The P99 year typically carries several times the mean downtime. This also shows why the repair-time distribution matters: real incident durations are lognormal, with a long right tail for the outage that starts at 3am with a stale runbook. A system that fails often and recovers in three minutes can beat a system that fails once and takes eight hours, even when their mean availabilities are identical.