error_budget_policy v1.0.0

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.

1. 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.

1. 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.