Error Budget
An error budget is the allowed amount of unreliability implied by an SLO, used to balance feature delivery against reliability work.
Definition
An error budget is 100% minus the SLO. If an SLO requires 99.9% success over 30 days, the error budget is 0.1% of valid requests, or about 43 minutes of full outage equivalent. The budget is spent by incidents, failed requests, and latency violations. When it is exhausted, the team prioritizes reliability work and limits risky changes until the budget recovers.
Context and scope
Error budgets turn reliability from an absolute goal into a managed resource. They give product and engineering a shared rule for when to ship and when to stabilize, and they make risk visible before an SLA breach.
Common misconceptions
- An error budget is a target to spend — it is a limit, not a quota that must be used
- A healthy budget means every change is safe — it permits risk, but individual changes still need canaries and rollback
- The budget only counts outages — partial failures, latency violations, and data errors also consume it
Anti-patterns
- Ignoring the budget because the SLO is "just an internal target"
- Freezing all releases after a single incident without examining the burn rate
- Measuring the budget from a different source than the SLO
Related concepts
Related examples
Authoritative source
The budget is a policy, not a metric
The error budget is derived from the SLO, but what the team does with it is a policy. A common policy: if the budget is healthy, ship features with normal controls; if the burn rate is high, slow risky changes and investigate; if the budget is exhausted, freeze risky releases until reliability improves. The policy must be agreed before an incident, not negotiated during one.
SLO 99.9% over 30 days -> error budget 0.1%
Budget in request terms: 0.001 x valid requests
Burn rate: observed error rate / allowed error rateA burn-rate alert fires when the budget is being consumed much faster than the window allows. It catches a severe incident earlier than waiting for the monthly budget to run out. Multiple windows (fast and slow) reduce both false alarms and late detection.
Separate budget from cause
The budget says how much unreliability is allowed; it does not say why it happened. A single incident can exhaust a month’s budget, or a low-level chronic error can drain it slowly. Investigate both. Do not use the budget to suppress reporting of failures; the measurement must remain honest even when the number is uncomfortable.
Communicate trade-offs
Product owners need to understand that a reliability target implies a change policy. When the budget is exhausted, the trade-off is explicit: reliability work takes priority over new features. Without that agreement, the budget becomes a number that engineering reports and product ignores.
When to use it
Use an error budget when an SLO exists and the organization needs a shared rule for release risk. The advantage is a principled balance between velocity and stability; the drawback is the discipline of measurement and the willingness to enforce the policy. Compared to ad hoc freeze decisions, a budget is transparent but only as good as the SLO behind it.