An error budget is the amount of unreliability your service is allowed to have before you must stop shipping features and prioritize fixing reliability instead, calculated as 100% minus your service level objective. If your SLO is 99.9% of requests succeeding over 30 days, your error budget is the remaining 0.1% — a fixed, spendable allowance of acceptable failure. The point of an error budget is not to tolerate failure for its own sake; it is to give engineering and product teams a shared, pre-agreed number that settles the velocity-versus-reliability argument with data instead of opinion.
How it works
Start with a service level indicator (SLI) — a metric you can actually measure, like the percentage of HTTP requests returning a non-5xx status. Set a service level objective (SLO) — the target for that metric over a time window, like 99.9% over 30 rolling days. The error budget is what is left: 0.1% of requests, or roughly 43 minutes of full downtime equivalent per month, computed however your failure mix actually breaks down.
Every failure — an outage, a bad deploy, a slow endpoint that breaches latency SLIs — draws down that budget. As long as budget remains, teams ship normally, including changes that carry some risk. Once the budget is exhausted, the pre-agreed policy kicks in: feature launches pause, and the team's priority shifts to reliability work until the budget resets with the next window.
Turning a budget into a policy
A number alone changes nothing — the policy that acts on it is what makes an error budget useful.
| Budget state |
Typical policy response |
| Budget mostly intact |
Ship normally, including moderate-risk changes |
| Burn rate elevated (fast consumption) |
Alert on-call, review recent changes, consider slowing deploys |
| Budget nearly exhausted |
Freeze new feature launches; only reliability and bug fixes ship |
| Budget fully exhausted |
Hard freeze on risky changes until the window resets or budget recovers |
Burn-rate alerting matters more than the raw remaining balance. A service that will exhaust its monthly budget in six hours at the current failure rate needs a page now, even if 95% of the budget is technically still unspent — multi-window burn-rate alerts (comparing a 1-hour and 6-hour burn rate together) are the standard way to catch this without paging on every minor blip.
Common mistakes
- Defining an error budget with no SLO behind it. The budget is derived from the SLO — without a documented target, "our error budget" is just a vague feeling, not a number anyone can act on consistently.
- Writing a policy with no enforcement. A budget-exhaustion policy that gets overridden every time a big feature is due is decoration. If the freeze never actually happens, the budget is not doing its job of arbitrating priorities.
- Using uptime as the only SLI. Uptime hides latency degradation, partial failures, and slow-but-technically-successful requests. Most services need multiple SLIs — availability and latency at minimum — to represent what users actually experience.
- Resetting the budget arbitrarily after an incident. The whole point of a fixed time window is that a bad incident should visibly cost budget and visibly constrain the following weeks. Resetting it early to avoid an uncomfortable freeze defeats the purpose.
FAQ
How do you calculate an error budget in practice?
Take (100% minus SLO) times total requests, or total time, in the measurement window. A 99.9% SLO over 30 days leaves roughly 43 minutes of full-outage-equivalent budget, distributed across however failures actually occur — many small partial failures or one longer outage.
What is burn rate, and why does it matter more than remaining budget?
Burn rate is how fast you are consuming budget relative to a sustainable pace. A high burn rate over a short window means you will exhaust the entire month's budget in hours if it continues, which deserves immediate attention regardless of how much budget is technically left.
Who decides the error budget policy?
It should be agreed between engineering and product leadership before an incident, not negotiated in the moment. A policy set under pressure during an actual freeze tends to get overridden by whichever feature feels most urgent that week.
Does spending the whole error budget mean an outage happened?
Not necessarily — it can also come from many small failures, elevated latency breaching an SLI, or a string of partial degradations. An exhausted budget reflects cumulative unreliability, not a single incident.
Where to go next
Error budgets are the concrete mechanism that separates SRE from DevOps as a practice rather than just a philosophy. To find reliability gaps before they burn your budget in production, see the chaos engineering guide for 2026, and if you are validating a service rewrite against your existing SLOs, the parallel-run migration pattern shows how to compare old and new systems before cutting over.