| name | audit-error-budget |
| description | Use when reviewing error budget consumption, setting burn rate alerts, or making reliability investment decisions based on budget status |
| source | Site Reliability Engineering (Google, 2016) Ch. 3; 'Alerting on SLOs' (Google SRE Workbook, 2018 Ch. 5); Alex Hidalgo 'Implementing SLOs' (2020) |
| tags | ["sre","error-budget","burn-rate","reliability","alerting","slo","operations"] |
| verified | true |
Audit Error Budget
Analyze error budget consumption to decide whether to invest in reliability work or continue shipping features.
Why This Is Best Practice
Adopted by: Google SRE teams; Spotify engineering; Atlassian reliability organization; formalized in Google's SRE Workbook as the standard method for balancing reliability against feature velocity
Impact: Google's original SRE book documents error budget policies eliminating the feature/reliability conflict by making trade-offs data-driven; organizations that implement error budget policies report reduced escalation frequency and faster incident resolution prioritization
Why best: Error budget is the mathematical expression of acceptable unreliability. Consuming it is not inherently bad — it means features shipped. Consuming it too fast is bad — it means users suffered unexpectedly. The audit identifies whether consumption is within the expected rate and triggers defined policy responses when it is not.
Steps
- Calculate current budget remaining —
budget_remaining = (current_error_rate - SLO_target) × window_length; express in minutes of downtime equivalent and percentage of budget consumed
- Calculate burn rate —
burn_rate = actual_error_rate / error_rate_allowed_by_SLO; a burn rate of 1.0 is neutral; above 1.0 depletes budget; below 1.0 recovers it
- Classify burn rate severity — fast burn (>14.4x over 1 hour): page immediately; slow burn (>1x over 3 days): ticket required; under 1x: healthy
- Identify consumption source — attribute budget consumption to deployments, infrastructure changes, or traffic spikes; use deployment markers in your metrics system
- Apply the error budget policy — if >50% consumed with >14 days remaining: reliability work enters the sprint; if 100% consumed: feature releases freeze until budget recovers
- Forecast end-of-window position — project current burn rate to end of measurement window; if trajectory shows overrun, intervene now
- Document and present findings — monthly error budget review should include: budget consumed, top three consuming incidents, policy actions taken, and trend vs. prior periods
Rules
- An error budget review is mandatory input to sprint planning — reliability investment must be data-driven, not reactive
- Budget consumption attributed to planned maintenance must still count against the budget unless users were notified in advance
- Burn rate alerts must use multi-window detection (1-hour + 6-hour) to avoid both alert fatigue and missed slow burns
- Never reset the error budget manually mid-window to avoid policy consequences
Examples
Scenario: SLO is 99.9% over 28 days. After 14 days, error rate is 0.3% (3× the allowed 0.1%). Burn rate = 3.0. Budget consumed: 60% with 50% of window remaining. Policy trigger: reliability work enters next sprint; no new feature releases until burn rate drops below 1.0.
Common Mistakes
- Reviewing error budget only after incidents: by the time you review, the policy consequence has already been delayed
- Attributing all consumption to unavoidable causes: this removes the feedback loop that improves reliability
- Setting burn rate alerts that only trigger at 100% consumption: at that point, users have already suffered the full impact
When NOT to Use
- No SLO has been defined for the service yet — error budget auditing requires a target SLO as the denominator; run
design-slo first to establish the baseline before attempting an audit.
- The service is in alpha or private beta with fewer than 100 users — statistical noise in error rates at low traffic volumes makes burn rate calculations meaningless and will trigger false policy responses.
- The team is in the middle of a major incident with active user impact — auditing historical budget consumption during an active outage delays mitigation; complete incident response first and run the audit during the post-incident review.
