Calculate SLA uptime percentages and error budgets. Convert between nines of availability and allowed downtime.
Type an availability target and get the downtime it permits. Then keep going, because that number on its own settles almost nothing. This tool has seven tabs: availability to downtime, error budget, burn rate, architecture composition, a Monte Carlo simulation of annual downtime, a service tier comparison, and a downtime cost estimator. The interesting ones are the middle three, because they answer the questions the simple conversion raises — how fast am I spending the budget, what does my actual dependency chain compose to, and how much of my exposure is the unlucky tail rather than the average.
Everything runs in the browser. No account, no upload, nothing sent anywhere. Inputs are mirrored into the URL, so a link reproduces the exact scenario, and the Monte Carlo run is seeded so a given seed reproduces the same distribution.
The conversion is downtime = period seconds × (1 − availability/100). The tool uses a 30-day month (2,592,000 s), a 90-day quarter, a 365-day year and a 7-day week, and shows every period at once so you can see the same target expressed the way each audience will hear it.
| Availability | Per day | Per week | Per 30-day month | Per 365-day year |
|---|---|---|---|---|
| 99% | 14 m 24 s | 1 h 40 m 48 s | 7 h 12 m | 3 d 15 h 36 m |
| 99.5% | 7 m 12 s | 50 m 24 s | 3 h 36 m | 1 d 19 h 48 m |
| 99.9% | 1 m 26.4 s | 10 m 4.8 s | 43 m 12 s | 8 h 45 m 36 s |
| 99.95% | 43.2 s | 5 m 2.4 s | 21 m 36 s | 4 h 22 m 48 s |
| 99.99% | 8.64 s | 1 m 0.5 s | 4 m 19.2 s | 52 m 33.6 s |
| 99.999% | 0.86 s | 6.05 s | 25.92 s | 5 m 15.4 s |
Read down any column and the shape of the problem appears. Each additional nine divides the allowance by ten. Going from 99.9% to 99.99% takes your monthly allowance from 43 minutes and 12 seconds to 4 minutes and 19 seconds — and 4 minutes is less time than most organisations take to page a human, let alone have that human log in and understand what is happening. That is the real reason the cost curve is exponential: below roughly five minutes of monthly budget, every incident has to be detected and remediated automatically, which means health checks, automatic failover, progressive rollout with automated rollback, multi-zone or multi-region redundancy, and the on-call and testing culture to keep all of it working. You are not buying more uptime, you are buying a different engineering organisation.
The period definitions matter more than they look. A vendor quoting 99.9% monthly and a vendor quoting 99.9% annually are offering different products — the annual figure lets a single 8-hour outage sit inside the commitment, while the monthly figure would breach on it and breach again the following month if it recurred. Always check the measurement window, what counts as downtime, whether scheduled maintenance is excluded, and how the vendor measures.
If your SLO and your SLA are the same number, you have no warning margin: the first time you learn you have a problem is the day you owe credits.
The error budget is simply the complement of the SLO: budget = 100 − SLO, expressed as time over the window or as a count of failed requests. The tool computes both. For a 99.9% SLO over 30 days it is 43 minutes and 12 seconds; if you switch to request-based accounting and give it a request volume, it computes the allowed error count as floor(requests × budget percent / 100) — 10 million requests at 99.9% gives 10,000 allowed failures — and subtracts the errors you have already spent to show what remains, as an absolute number and as a percentage.
The reason to frame reliability as a budget rather than a target is that it turns an argument into arithmetic. Product wants to ship; SRE wants stability; nobody wins that argument by asserting harder. A budget makes the trade explicit and gives it a governing rule:
Request-based and time-based budgets do not measure the same thing, and it is worth knowing which you are quoting. A 10-minute outage at 3 a.m. costs very little request budget and a full 10 minutes of time budget. The same outage at peak costs a great deal of request budget. For user-facing services the request-based figure is usually the more honest one.
Burn rate is current error rate / error budget percent. A burn rate of 1 spends the budget exactly over the window; 2 spends it in half the window; 0.5 leaves half of it unspent. Time to exhaustion is window days / burn rate, so a 30-day window burning at 4× is gone in 7.5 days. The tool grades the result — below 0.5 excellent, up to 1 healthy, up to 2 elevated, up to 5 warning, above 5 critical — which is a reasonable set of default thresholds for a first alerting policy.
It also derives multi-window alert thresholds using threshold = window hours / (alert window hours × (100 / consumption percent)) at 5% consumption. For a 30-day window that gives a fast-burn threshold of 36 over a 1-hour alerting window, and a slow-burn threshold of 6 over a 6-hour window. The point of having two is that a single threshold cannot be both fast and quiet: a low threshold catches the slow leak but pages you on every blip, and a high one is silent until the budget is already gone. Alert on a high burn rate sustained over a short window and a moderate burn rate sustained over a long one.
This is the tab that changes people's numbers. Availability in series multiplies. If a request has to traverse DNS, a load balancer, app servers, a database and a third-party API, the composite is the product of all of them, and it is always lower than the worst single component.
The default architecture demonstrates it. DNS at 99.99% (single), load balancer at 99.99% (single), app servers at 99.9% each in a 2-instance group needing 1, a database cluster at 99.95% each in a 3-instance group needing 2, and a third-party API at 99.9% (single). The composite is 99.8599% — about 12.27 hours of downtime a year. The weakest single link is 99.9%, or 8 hours 45 minutes. Quoting the weakest link would understate annual exposure by roughly three and a half hours, and that is with two components already redundant.
Redundancy is modelled as a k-of-n group with a common-cause correlation factor — the classic beta-factor model:
A_group = (1 − ρU) × Σ(j = k..n) C(n, j) (1 − u)^j u^(n−j), where U = 1 − A, u = (1 − ρ)U
With ρ = 0 this reduces to the textbook binomial, and with k = 1 to the familiar 1 − (1 − A)^n. With ρ = 1 it reduces to A: redundancy buys nothing at all when every replica shares the failure cause. That is the honest part of the model, and it is the part most availability arithmetic omits. Shared power, a shared control plane, a shared config push, a shared certificate expiry, the same bug in the same version on every replica — these are the things that take out all n instances at once, and they set a floor no amount of replication can go below.
The correlation sweep chart makes the ceiling visible: it recomputes annual downtime for the whole design across every correlation value from 0 to 1. In the default stack, perfectly independent replicas would give 99.8798% (10.53 hours a year) against the 12.27 hours the configured correlation produces. The gap between those two curves is what better failure isolation is worth in hours — a far more useful input to a design conversation than an assertion that redundancy is good.
Components can be driven by availability directly or by MTBF and MTTR, using A = MTBF / (MTBF + MTTR), with the inverse available so you can ask what MTBF a target implies at your current repair time. Individual components can be toggled off to see what removing a dependency is worth. The panel also reports each component's effective availability, its annual downtime contribution, and what it would be worth with perfectly independent replicas.
The analytic composite gives you a long-run mean. It does not tell you the chance that this particular year breaches your SLA, which is the question that actually costs money. The Monte Carlo tab simulates independent years of the composed architecture as an alternating renewal process — exponential time to failure at rate 1/MTBF, then a repair drawn from a chosen distribution — and reports the distribution of annual downtime: mean, p50, p90, p95, p99, maximum, and the share of simulated years exceeding your SLA allowance.
Three repair models are offered, and the choice matters:
That tail is the whole point. Two designs with identical mean downtime can have very different p99 years, and it is the p99 year that generates the credits, the escalation and the customer call. The run count and the seed are both adjustable, and the seed makes results reproducible for a document or a review.
The tier comparison tab lays four illustrative support tiers side by side — 99%, 99.5%, 99.9% and 99.99% with example response times, support hours and prices — and converts each to monthly and annual downtime. It is a template for structuring a tiered offer, with placeholder pricing rather than a market survey; replace the numbers with your own.
The cost estimator turns downtime minutes into money. Revenue loss is annual revenue / minutes per year × downtime minutes × industry multiplier; productivity loss is impacted employees × hourly cost × downtime hours. The industry multipliers are coarse relative weightings supplied by the tool, not measured market data — they are there so you can express that an hour down costs a bank more than it costs a university. The output is a defensible order-of-magnitude figure for a business case. It is not a forecast, and it does not attempt to price reputational damage, contractual penalties or churn, which are frequently the largest terms.
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.