Error Budget Policy — A Field Guide

The error budget is the idea in the Google SRE book that turns "be more reliable" from an unbounded mandate into a number you can spend. If your SLO is 99.9% availability over 30 days, your error budget is the remaining 0.1% — about 43 minutes of allowed downtime or bad requests. The budget isn't a target to hit; it's a quantity to spend deliberately, on releases, risky migrations, and experiments, instead of losing it to unplanned outages.

SLOs, SLIs, and where the budget comes from

The budget is derived, not chosen directly. You pick a service level indicator (SLI) — the metric that reflects user-perceived health, usually a ratio like successful requests over total requests, or latency under a threshold over total requests. You then set a service level objective (SLO) as a target for that SLI over a window, e.g. 99.9% of requests succeed over a rolling 30 days. The error budget is simply 1 - SLO expressed as an allowance: at 99.9% over 30 days that's roughly 43.2 minutes of full downtime, or a proportionally larger amount of partial degradation if you're measuring a success ratio rather than binary up/down.

The SLO should sit below what the SLA promises externally, if there is one — the SLA is what you're contractually bound to and often carries penalties, the SLO is your internal early-warning target you can miss without a support ticket cascading into a contract dispute.

SLO: 99.9% successful requests, 30-day rolling window
Error budget = (1 - 0.999) x 30 days
             = 0.001 x 43,200 minutes
             = 43.2 minutes of allowed bad-request time

Burn rate = (actual error rate / allowed error rate)
  Burn rate 1.0  -> budget exhausted exactly at window end (on pace)
  Burn rate 10.0 -> budget exhausted in 1/10th of the window (~3 days)
  Burn rate 60.0 -> budget exhausted in ~12 hours - page immediately

Burn rate: the signal that actually pages someone

Raw "percent of budget remaining" is a bad paging signal because it reacts too slowly to a fast-moving outage and too twitchily to noise. Burn rate — how fast you're consuming the budget relative to a sustainable pace — is what the SRE workbook builds multi-window alerting around: a short window (e.g. 5 minutes) catches fast, severe burns; a longer window (e.g. 1 hour or 6 hours) catches slow leaks that a short window would miss entirely. Alerting on a high burn rate sustained across both a short and long window cuts false pages from single blips while still catching genuine incidents fast.

The policy: what happens when the budget runs out

The error budget only changes behavior if there's a written policy attached to it, agreed on before the budget is exhausted, not negotiated in the moment. The canonical Google SRE policy: when the error budget for a service is exhausted, feature releases freeze until the service is back within budget, and the team's priority shifts to reliability work — fixing the root cause of the burn, not just riding out the freeze. Launches can still happen with product-team sign-off if the risk is judged acceptable, but that's an explicit escalation, not the default.

Why 100% is the wrong target

A target of 100% reliability is unachievable in any system with a network, a dependency, or a deploy pipeline, and chasing it anyway has a real cost: every increment of reliability past what users can perceive is engineering time not spent on features, paid for in slower iteration with no user-visible benefit. The error budget reframes the conversation from "why did we have an outage" to "did we spend the budget on something worth it" — a budget spent on a risky-but-valuable migration is a good outcome; the same budget burned by an untested config push is not, even though both consume the identical 43 minutes.

None of this works without picking an SLI that actually reflects what users experience and an SLO the org will hold itself to under pressure — the budget and the freeze policy are just arithmetic and process layered on top of that choice. Get the SLI wrong and the budget tracks the wrong thing precisely.