---
name: "error_budget_policy"
description: "Define and enforce error budgets: SLO math, burn-rate alerts, freeze policy, and the blameless review when a budget blows. Triggers on 'set up SLO alerting', 'error budget policy', 'when do we freeze features', or post-breach review work."
---

# Error Budget Policy

## Purpose

Turn an SLO from a number on a dashboard into decisions: how much failure a team can afford, when an alert should wake someone up, when feature work stops, and how to run the review after a budget blows. An error budget without a pre-agreed policy is decoration.

## Workflow

1. **Define the SLO.** One SLO per critical user journey (not one for the whole service). Measure at the user boundary. Set the target from the last 4 weeks of real performance, minus 5-10 points. Never aspiration, never tighter than a dependency's SLO without a mitigation plan, never 100%.
2. **Compute the budget.** Run `bin/budget` with the SLO target and window. It prints the budget in minutes, in allowed requests, and the downtime-per-month table. See `references/budget-math.md` for the formulas behind it.
3. **Write the burn-rate alerts.** Use the multi-window, multi-burn-rate pattern from Google's SRE Workbook (chapter 5, "Alerting on SLOs"): each severity pairs a long window (proves the burn is real) with a short window (proves it is still happening, so the alert resolves fast after recovery). Canonical values for a 30-day window:
   - Page: 14.4x burn, 1h long + 5m short (2% of budget gone in 1h)
   - Page: 6x burn, 6h long + 30m short (5% of budget gone in 6h)
   - Ticket: 3x burn, 1d long + 2h short (10% of budget gone in 1d)
   - Ticket: 1x burn, 3d long + 6h short (10% gone in 3d)
   Thresholds scale with the SLO window; `bin/budget` scales them for you. PromQL examples live in `references/budget-math.md`. A freshly created SLO must not fire until it has a full long window of history, or the first bad check pages on garbage math.
4. **Write the freeze policy.** Agree the ladder BEFORE the first breach, with product and engineering both in the room. It is not renegotiated mid-incident. Default ladder:
   - Above 50% remaining: ship normally, run experiments.
   - 20-50%: risky changes get senior sign-off; reliability bugs get priority.
   - Below 20%: feature work slows; reliability fixes jump the queue; no non-critical releases.
   - Exhausted: feature freeze. Reliability work only until the budget recovers.
5. **Hold the blameless review.** When the budget is burned by a single incident, run a postmortem before releases resume: written within 48 hours, focused on what broke in the system (never who). Template in `references/postmortem-template.md`.

## Output Contract

- SLO statement: journey, SLI, target, window, what counts as bad.
- Budget in concrete terms (minutes and requests) from `bin/budget`.
- Four burn-rate alert rules with windows, thresholds, and routing.
- A written freeze ladder with an owner for exceptions.
- If a budget blew: a completed postmortem with action items that have owners and deadlines.

## Operating Rules

- Every factual claim here is verified: thresholds come from Google's SRE Workbook ch. 5 as reproduced across the sources in the skill's research notes; budget arithmetic is 1 minus the SLO target times the window. If a number does not check out, cut it or mark it as an estimate.
- The budget is a prioritization tool, never a punishment tool. Never use burn rate to blame a team.
- No policy, no SLO. Ship the freeze ladder in the same document as the SLO, not in a follow-up that never comes.
- Alert only on burn rate for paging. Flat error-rate thresholds are either too noisy or too slow.
- Each alert must link to a runbook; each runbook must end with a remediation action.