Error Budgets

How to derive the budget from the SLO, what an error-budget policy looks like, and when to actually halt launches.

Overview

What an error budget is

An error budget is the operational expression of an SLO. The math is one line: error_budget = 1 − SLO, applied over the SLO's measurement window.

The worked example (Workbook Ch 2)

SLO — 99.9%
Window — 30 days
Requests — 3 million
Error budget — 3,000 allowed errors
One incident with 1,500 errors — Burns 50% of the budget

> [!NOTE] That 50% burn from a single incident is the lever. It makes reliability a number the whole team can see.

The error-budget policy

The error-budget policy (EBP) is the org-level contract that turns the budget into binding action. Workbook Ch 3, verbatim:

> "If the service has exceeded its error budget for the preceding four-week window, we will halt all changes and releases other than P0 issues or security fixes until the service is back within its SLO."

Permission, not punishment

Not a penalty — Exists "not to serve as punishment for missing SLOs"
A permission — Gives teams "permission to focus exclusively on reliability when data indicates that reliability is more important"
Enforced from the top — Disagreements on whether the budget is exhausted, or whether an incident counts, go to the CTO

> [!IMPORTANT] Escalating to the CTO is a deliberate choice. It forces the org to take the policy seriously.

Key concepts

Error budget formula: budget = 1 − SLO, applied over a rolling measurement window. Worked example for 99.9% SLO over 30 days: 0.1% × 30 days × 24 h × 60 min = 43.2 minutes/month of "allowed unreliability." At 10K RPS: 0.1% × 25.92 billion requests = 25.92 million failed requests allowed. The budget is denominated in BOTH time AND requests — pick whichever makes more sense for the context.
Burn rate: How fast you're consuming the error budget vs the steady-state rate that would exhaust it exactly over the SLO window. 1× burn = budget will run out exactly at end of window (sustainable). 14.4× burn = budget gone in ~2 hours (emergency — page on-call). Burn rate × window = % of budget consumed. The multi-window multi-burn-rate alerting pattern (Workbook Ch 5) uses 14.4× / 6× / 1× thresholds at fast/medium/slow windows respectively.
Error-Budget Policy (EBP): The org-level WRITTEN CONTRACT that turns the math into binding action. Workbook Ch 3 provides a template with: metadata header, service overview, goals/non-goals, SLO miss policy, outage policy, escalation policy. Signed by SRE lead, dev lead, product lead. Without a signed EBP, the budget is just a number with no consequences — defeats the purpose. The signatures matter when freeze-time politics hit.
4-week halt rule (Workbook Ch 3 verbatim): "If the service has exceeded its error budget for the preceding four-week window, we will halt all changes and releases other than P0 issues or security fixes until the service is back within its SLO." Why 4 weeks: a single bad day is noise; 4 weeks is signal. Why halt: gives engineering time to focus on reliability without competing with feature pressure. Why P0/security exceptions: you can't halt safety fixes.
Postmortem trigger (20% rule): Workbook Ch 3 template: any SINGLE incident that consumes more than 20% of the quarterly error budget triggers a mandatory postmortem. This catches "one bad day" within an otherwise healthy quarter. Without this trigger, a 2-hour outage in a quarter where you were otherwise at 30% budget consumption would never be analyzed because the quarter still looks healthy.
Permission, not punishment (cultural framing): The Workbook is explicit: EBP "is not to serve as punishment for missing SLOs" but rather to "give teams permission to focus exclusively on reliability when data indicates that reliability is more important." A team using 100% of its budget is doing the right thing — they're shipping at the maximum velocity SLO compatibility allows. A team consistently under-spending budget (e.g., 30%) is being too cautious and leaving feature velocity on the table; should tighten the SLO or accelerate launches.

When to use it

Designing the launch-vs-reliability decision rule for a service
Justifying a launch freeze to dev teams who feel the SRE is being arbitrary
Sizing the impact of a single incident — "how much of the budget did this burn?"
Tuning alerting thresholds via burn rate (see C8 multi-window multi-burn-rate)

Interview questions

Walk me through the error-budget policy at a service level.
A team is at 110% of budget consumed. What should happen?
My team consistently never burns more than 30% of our budget. Is that good?
Why is the halt rule based on a 4-week rolling window specifically?
How does an error budget interact with burn-rate alerting?