---
name: "slo-error-budgets"
description: "Set up SLOs, SLIs, and error budgets for a small team: define indicators, pick targets, wire burn-rate alerts, and write the release-freeze policy. Use when a service needs reliability targets, when alerting pages on raw thresholds, or when deciding what to do after an SLO breach."
metadata: { "includeInPrompt": true }
---

# SLOs and Error Budgets

## Purpose
Turn "keep the service reliable" into numbers a small team can actually run: an SLI that measures what users feel, an SLO target over a rolling window, an error budget you spend on risk, burn-rate alerts that page on real incidents, and a written policy for what happens when the budget runs dry.

## Workflow
1. **Define SLIs first.** For request/response systems use availability (successful requests / valid requests) and latency as a ratio (requests under threshold / all requests), not raw p99. For pipelines use freshness, completeness, correctness. Measure at the point closest to the user (load balancer, gateway). Count only valid events: exclude load-test traffic and malformed client requests from the denominator.
2. **Pick an SLO target and window.** A rolling 30-day window is the default; rolling avoids the "reset on the 1st" distortion. error_budget = 1 - SLO. For 99.9% the budget is 0.001, which is ~43 minutes of downtime per 30 days. Never set 100%: an impossible SLO either kills velocity or gets quietly ignored.
3. **Alert on burn rate, not thresholds.** burn_rate = current error ratio / error_budget. Burn rate 1 means you burn exactly the budget by window end. Use multi-window, multi-burn-rate (Google SRE Workbook Ch. 5): each alert fires only when BOTH a long window and a short window (1/12 the long) exceed the burn-rate threshold.
   - Page: 14.4x over 1h and 5m (2% of a 30-day budget gone in an hour).
   - Page: 6x over 6h and 30m (5% gone in 6 hours).
   - Ticket: 1x over 3d and 6h (10% gone in 3 days, worth a workday fix).
   The long window proves the problem is real; the short window proves it is still happening, so the alert clears when the fix lands instead of firing for an hour after. See `references/burn-rate-alerting.md` for the worked PromQL.
4. **Write the error budget policy.** One page, signed by product and engineering leads, or it is theater. It states: what happens at or above SLO (releases proceed normally); what happens on exhaustion (halt all changes and releases except P0 issues and security fixes until back within SLO); when reliability work is mandatory (a code bug or procedural error caused the miss; a postmortem showed a hard dependency could have been softened); and when feature work may continue (company-wide outage, another team's service that already froze, budget burned by out-of-scope users). Small-team escalation ladder: >50% budget left ships confidently, 25-50% slows risky changes, <25% freezes new features. The policy is not a punishment; it gives the team permission to stop shipping and fix reliability. See `references/error-budget-policy-template.md`.
5. **Operationalize it.** Every burn-rate alert links to a runbook and names the owning team. Report budget remaining weekly to service owners. One incident burning >20% of budget triggers a mandatory blameless postmortem. Revisit SLO targets each quarter: if you never touch the budget, the target may be too loose; if you exhaust it monthly, it is too tight or the system needs real reliability work.

## Output Contract
A small team running this skill ends up with: 2-5 SLIs documented with queries, one SLO target and window per SLI, the error budget in plain units (minutes per month), 3 burn-rate alert rules deployed, a signed error-budget policy, and a weekly budget report. If any of these is missing, the job is not done.

## Operating Rules
1. Every factual number in a plan comes from a source or from the math in `references/burn-rate-alerting.md`. Never invent SLO targets from habit: they come from what the business actually needs.
2. Page on symptoms only (the SLO is breaching). Cause signals (CPU, queue depth, disk) go to dashboards or tickets, never the pager. An alert that would not have been wanted if nothing else was happening is noise: delete or demote it.
3. Keep SLOs tighter than any contractual SLA, so the budget warns you before penalties bite.
4. SLO targets are a product decision, not an engineering one. Do not tighten a target without the product lead agreeing the freeze policy applies to their roadmap too.
5. When the policy's freeze rule would surprise anyone, it has not been socialized enough. Walk through it before the first incident, not during it.