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: An error budget is the allowed bad fraction, multiplied by the eligible events in the SLO window. Burn rate compares the observed bad fraction with that allowance; a written policy determines how the result changes release and incident decisions.
Define what counts before doing arithmetic
A service-level indicator (SLI) measures an outcome, such as the proportion of eligible booking requests that return a correct acknowledgement within a deadline. A service-level objective (SLO) sets the target and the window: for example, 99.9 percent good requests over 30 days. These are illustrative choices; the objective should reflect the service's users and consequences of failure.
The allowed bad fraction is 1 - 0.999 = 0.001. For one million eligible requests, the allowance is 1,000 bad requests. If 650 requests are bad, 350 remain within that allowance. A slow correct response can count as bad under a latency objective, while a fast incorrect response can count as bad under a correctness objective. State the rule explicitly.
Keep the denominator honest. If valid requests rejected because the service is overloaded count as user failures, they belong in the indicator even if the application never handled them. Requests excluded for a documented reason, such as invalid syntax, must use the same rule in both the good and eligible counts. Otherwise a change in filtering can look like a reliability improvement.
Minutes and requests answer different questions
For a time-based availability indicator, a 30-day window contains 43,200 minutes. Multiply that duration by the allowed fraction to obtain the time allowance.
| Objective | Allowed fraction | Time allowance over 30 days |
|---|---|---|
| 99% | 1% | 432 minutes |
| 99.9% | 0.1% | 43.2 minutes |
| 99.95% | 0.05% | 21.6 minutes |
| 99.99% | 0.01% | 4.32 minutes |
| 99.999% | 0.001% | 25.92 seconds |
Do not apply this table directly to a request-based objective. A minute of failure during peak traffic can consume more request budget than an hour at night. In a teaching example, 1,000 failures among one million eligible requests consume the whole 99.9-percent request allowance regardless of how many minutes those failures occupied.
The smallest time allowances also expose the role of recovery design. A manual response may take longer than the entire allowance, so meeting such an objective can require redundancy or automated recovery before a human responds. That is a design implication, not a promise that automation guarantees the objective.
Read burn rate as a ratio
Suppose an hour contains 100,000 eligible requests and 500 bad ones. The observed bad fraction is 500 / 100000 = 0.005, or 0.5 percent. Against a 99.9-percent objective, burn rate is 0.005 / 0.001 = 5. The service is failing at five times the allowed fraction during that hour.
Burn rate has no unit. It is neither a downtime percentage nor a count of failures. A sustained burn of one would consume an initially full budget over the objective window under steady traffic. Predicting when the remaining budget runs out also requires traffic assumptions and how much has already been spent. A rolling window complicates the prediction because old failures and eligible requests are leaving the window.
For alerts, a long window detects sustained budget consumption while a short confirmation window checks that the problem remains active. A brief recovered incident can leave the long-window rate high. Missing samples need a monitoring-health check rather than being interpreted as zero failures. Google's SLO alerting chapter explains this multi-window approach and its low-traffic limitations.
Agree what changes when the budget is threatened
Choose the policy before a release dispute. A team could restrict feature rollouts during an active incident, assign reliability work when remaining budget is low, and require explicit exceptions once the allowance is exhausted. The exact restrictions are an organizational decision. A critical security repair or an incident mitigation may need to proceed even during a freeze.
A healthy budget does not approve an unsafe migration. It says how the service has performed under the chosen indicator; schema compatibility, security and recoverability remain release requirements. Conversely, an exhausted rolling-window budget can remain exhausted after service recovery. Define when restrictions lift rather than waiting for a dashboard to imply the answer. Google's example error-budget policy illustrates written restrictions and exceptions; it is an example to adapt, not a rule imposed on every team.
Self-check
A fixed reporting window has two million eligible requests and a 99.95-percent objective. There are 700 bad requests so far. In the most recent interval, 200 out of 50,000 requests are bad. Calculate the allowance, remaining count and recent burn before reading on.
The allowance is 1,000 bad requests and 300 remain. The recent bad fraction is 0.4 percent; divided by the allowed 0.05 percent, burn is eight. You cannot derive a reliable exhaustion time from eight alone without the remaining traffic assumptions. Use the budget calculation lesson to practise that forecast, then the alerting question to choose a response.