Error Budget Calculator

Overview

An SLO is a promise expressed as a ratio: this fraction of requests will succeed. Its useful corollary is the remainder — the error budget, the amount of failure you are permitted before you have broken the promise.

Framing reliability as a budget changes the conversation. “Do not break anything” is not an engineering target, because it prices risk at infinity and therefore forbids shipping. “You have 43 minutes of unavailability this month and you have spent 12 of them” is a target you can plan against.

This calculator converts an SLO into three numbers: the budget as a percentage, the allowed unavailability for your window, and — if you supply a request count — the number of individual failures that fits inside it.

How to use

1. Enter the SLO you are committing to, as a percentage.
2. Set the window in days. 30 is the usual rolling month; 7 works for a faster feedback loop; 90 matches a quarterly review.
3. Optionally enter the request volume for that window to get the failure count.

Reading the numbers

Error budget is simply 100% − SLO. It looks trivially small next to the SLO and that is the point: the difference between 99.9% and 99.99% is a tenfold reduction in what you are allowed to spend, which is why each additional nine costs so much more than the last.

Allowed downtime is the budget applied to the window as wall-clock time. It is the number most useful for talking to people outside the team, because “about 43 minutes a month” is concrete in a way that “99.9%” is not.

Allowed failed requests is the same budget applied to volume. This is the number to plan against, because it maps directly onto what you can observe in your metrics — a count of 5xx responses, or of requests over your latency threshold.

Time-based and request-based budgets are not the same

Two incidents can consume identical time budget and wildly different request budget, and vice versa.

A five-minute total outage at 03:00 costs five minutes of downtime and very few requests. A day-long degradation where 0.5% of requests fail costs almost no “downtime” by a naive definition and can exhaust a month of request budget.

Users experience the second one. If you only measure availability as time, you will systematically under-count the failures that annoy people most, because partial failures do not register as downtime at all.

The usual resolution is to define the SLI as a ratio of good events to valid events — successful requests over total requests, or fast requests over total requests — and to derive a time-based figure only for communication.

What actually consumes the budget

The mistake is treating the budget as headroom for incidents. In practice it is shared with everything that makes requests fail:

• Deploys. Even a clean rollout drops connections unless every layer drains properly.
• Planned maintenance. If it is user-visible, it counts, whether or not you announced it.
• Dependency failures. Your budget is spent by your provider’s incidents, and you did not get a vote.
• The long tail. Individual timeouts, retries that exhausted, one bad node. These rarely become incidents and they add up.

Which is why teams that budget for 100% consumption of an error budget go over. Plan to spend a fraction of it on incidents and leave the rest for the ordinary cost of operating.

Examples

• 99.9% over 30 days — about 43 minutes. One bad deploy with a slow rollback can spend most of a month.
• 99.95% over 30 days — about 22 minutes. This is the point where manual rollback stops being fast enough and you need automation.
• 99.99% over 30 days — about 4 minutes. Achievable only with multi-region failover that engages without a human in the loop.
• 99.999% over 30 days — about 26 seconds. Detection alone typically takes longer than this, so the architecture has to tolerate faults rather than respond to them.

Each step up is roughly a tenfold reduction in permitted failure and a step-change in cost. Choose the SLO from what users actually need, not from how many nines sound impressive — an internal batch pipeline at 99.99% is money spent for nobody’s benefit.

Notes

The window is treated as exactly the number of days you enter, so a 30-day month is 2,592,000 seconds. Calendar months differ by up to three days, which matters if you are reconciling against a contract; a rolling 30-day window is the more common operational choice and it sidesteps the problem.

The failed-request count is truncated, not rounded, because a partial failure is not a thing you can spend.

For availability expressed as a contractual figure with penalty tiers, use the SLA calculator. It answers the neighbouring question — how much downtime a given availability promise permits — without the request-volume side.