Error budgets: the arithmetic and the decision it forces
An error budget turns reliability from an opinion into a number, and the number is only worth having if spending it changes a decision. The arithmetic takes ten seconds; the policy is the hard part, and the burn-rate alerting that falls out of it is what fixes on-call noise.
TL;DR: Error budget is one minus your SLO, expressed as time or as a count of failed requests over a window. 99.9 percent is about 43 minutes a month, 99.95 about 21.6, 99.99 about 4.3. If exhausting it does not stop a release, you do not have an error budget, you have a dashboard.
The numbers to know without hesitating
Over a 30-day window there are 43,200 minutes. The table is for a time-based availability SLI. A request-based SLO instead budgets a count of bad eligible requests; it does not directly translate to downtime when traffic varies.
| SLO | Budget | Monthly downtime |
|---|---|---|
| 99% | 1% | ~7.2 hours |
| 99.9% | 0.1% | ~43 minutes |
| 99.95% | 0.05% | ~21.6 minutes |
| 99.99% | 0.01% | ~4.3 minutes |
| 99.999% | 0.001% | ~26 seconds |
Twenty-six seconds is the useful one. It is less time than it takes an on-call engineer to open a laptop, which is the honest way to tell a stakeholder that five nines means no human in the loop and a fully automated recovery path, not a more careful team.
Why it is a budget rather than a target
Reliability past a point costs superlinearly, and the user cannot perceive the difference because their own network is worse than your service. So perfect availability is the wrong goal, and the budget names how much unreliability you are deliberately buying in exchange for change.
That reframes the argument between the people who want to ship and the people who want stability. There is no argument: while budget remains, ship. When it is gone, stop and repair. The number decides, not seniority.
The policy is the mechanism
An error budget with no consequence attached does nothing. The policy has to say what changes:
- Budget healthy: releases proceed normally.
- Budget exhausted: apply the agreed restrictions on feature releases and prioritize reliability work. Define exceptions for critical security fixes and incident mitigation, plus who authorizes them and when the restriction lifts.
Whether that freeze is absolute or negotiable is a real organisational decision, but it must exist and be written down before it is needed. Deciding mid-incident always resolves in favour of shipping.
Burn rate, and why it fixes alerting
Burn rate is how fast you are spending relative to the window. For a request-based SLI, burn rate is the observed bad-request fraction divided by the allowed fraction, using the same eligibility rules. With steady traffic and an initially full budget, a sustained rate of 1 consumes it over the SLO window; 14.4 consumes a 30-day budget in 50 hours. Remaining budget and traffic changes affect the actual exhaustion time.
That makes urgency proportional to consequence, which is what threshold alerting never achieves. A fast window (14.4x over an hour) catches a sharp outage in minutes. A slow window (3x over a day) catches gradual degradation a threshold would never notice. Requiring a short confirmation window alongside each stops a transient blip paging anyone.
Choosing the SLI, which is where honesty enters
Once a number gates releases, people stop choosing indicators that are easy to measure and start choosing ones a user would recognise. A load balancer health or reachability metric can look healthy while application responses are fast 500s. A correctly defined successful-response SLI at that same load balancer would detect them. Measure successful requests as the user would count them, from as close to the user as you can get.
Self-check
Compute the monthly budget for 99.95 percent without a calculator. Then: your service has burned 60 percent of its budget in four days and the team wants to ship a feature. What does your policy say, and who gets to overrule it?
Sources: Google SRE burn-rate alerts.