Mental model#
An error budget is the amount of bad service allowed by an SLO. Budget policy converts that remaining tolerance and its rate of consumption into explicit decisions about release pace, risk, and reliability work.
Mechanism and state flow#
- Calculate good and total events using the agreed SLI and window.
- Translate the SLO target into allowable bad events, then track remaining budget and burn rate.
- Define policy before exhaustion: who decides, which changes pause, and which reliability work takes priority.
- Use multiple windows to distinguish sudden incidents from a slow regression.
- Reset or revise policy only through the agreed product and engineering process, not to erase failure.
Concrete example#
A small failure rate burns quickly at high traffic
At 10 million eligible requests, a 99.9% objective allows 10,000 bad requests. A release causing 5,000 additional bad requests has spent half the window's budget even if dashboards still show 99.95% success.
Architecture consequence: Measure budget consumption and release impact, not only whether the current percentage is above a dashboard line.
Scaling and operational trade-offs#
| Option | Choose when | Cost or limit |
|---|---|---|
| Freeze risky releases | Budget is exhausted and changes are likely to worsen user harm. | Feature delivery slows while reliability recovers. |
| Continue reliability changes | A tested fix or protective control reduces burn. | Any production change can introduce new failure. |
| Different budgets by journey | Criticality and ownership differ materially. | Policy becomes harder to coordinate and explain. |
Failure diagnosis#
- Failure
- The team resets the window after a bad release to make the budget green.
- Impact
- The signal stops constraining risk and users absorb repeated unreliability.
- Detection
- Window definitions or exclusions change immediately after exhaustion without a product decision.
- Mitigation
- Keep window and policy versioned, record exceptions, and require accountable approval for target changes.
- Trade-off
- Governance slows ad hoc decisions during delivery pressure.
Checklist exercise#
Work the scenario before revealing your answer
- For 2,000,000 events and a 99.95% target, calculate allowed bad events.
- Write the policy at 25%, 75%, and 100% budget consumption.
- Name one reliability change allowed during a release pause and the evidence needed to ship it.
Use these prompts to extend the design. The useful answer is a reasoned change, not a memorized sentence.
- How fast is the budget burning?
- Which changes stop when it is exhausted?
- Who can approve an exception?
- How do you prevent a high-volume endpoint from hiding a critical low-volume journey?
Related practice problems
Use the manifest-backed prompts below to apply this lesson in a complete design.
- Error budget policyGoogle SRE Workbook
- Service level objectivesGoogle SRE
Sources reviewed 2026-09-04. Product-specific controls and threat assumptions still require current verification.