What is an error budget?
An error budget is the maximum amount of unreliability your service is permitted under its SLO. If your SLO is 99.9%, your error budget is 0.1% of requests — meaning 1 in 1,000 requests can fail within the measurement window without breaching the SLO.
Error budgets make the trade-off between reliability and feature velocity explicit. When the budget is healthy, teams can move fast. When it is low, reliability work takes priority over new features.
Burn rate explained
Burn rate measures how quickly you are spending your error budget relative to how quickly time is passing. A burn rate of 1.0 means you are consuming budget at exactly the pace that would exhaust it precisely at the end of the window — perfectly on track. A burn rate of 2.0 means you will exhaust the budget in half the remaining time.
| Burn rate | Meaning | Action |
|---|---|---|
| < 1.0 | Under budget | Normal operations |
| 1.0 – 2.0 | On pace or slightly over | Monitor closely |
| 2.0 – 6.0 | Burning fast | Reliability review |
| 6.0 – 14.4 | Slow burn alert threshold | Incident response |
| > 14.4 | Fast burn alert threshold | Immediate action |
What to do when budget is low
Define your response policy before you need it. A typical tiered response:
- Budget > 50%: Normal operations, feature work proceeds.
- Budget 10–50%: Reliability review before major releases.
- Budget < 10%: Reliability sprint, non-critical feature work paused.
- Budget exhausted: Feature freeze until budget recovers.
See Error Budgets Explained for a full guide to operationalizing error budgets on your team.