An SLO without a policy is a wish with a decimal point. The team writes 99.9% in a wiki, everyone nods, a bad deploy burns a third of the budget on a Tuesday - and nothing happens. No state changes, nobody pauses anything, the next risky release ships on schedule. The number watched you miss it and said nothing.
An error budget policy turns the number into a decision rule. Three numbers on one line, four states that are computed rather than felt, a named decider for every state, and a fraud list that keeps the number honest.
Count in minutes, not percentages. 99.9% over 28 days = 40.3 bad minutes per month you have chosen to spend on purpose. "0.1%" hides its smallness; "40 minutes" is small enough to feel. Cap SLIs at two per service - availability plus one latency threshold - or nobody maintains the line.
Four states, computed not felt:
- GREEN (>50% remaining): normal shipping. The state exists so its absence is loud.
- AMBER (20-50%): risky releases go first, not paused - a risky release is cheapest while there's budget to absorb its mistakes.
- RED (<20%): feature work on the affected service pauses, reliability work gets first pick, rollbacks mandatory pre-merge. One named lead announces the pause with the budget line pasted in - the number speaks, not the person.
- BLOWN (0%): automatic freeze on the service. Unfreezing needs a named human plus evidence: which failure modes the design work addresses. Budget recovers as bad minutes age out of the window - or faster, via design work.
The states are deliberately boring. Nobody has to be brave to declare a freeze; the arithmetic does it, and that removes the argument where arguments actually live: "should we pause the roadmap for reliability?" becomes "we're in RED, the policy says checkout pauses."
What spends the budget: minutes where real users were hurt by surprise. Communicated maintenance windows don't count (downtime by appointment). A failed deploy spends from first customer harm to full recovery - detection latency is budget spend, which is why MTTD belongs in the metrics report. Partial impact counts fractionally, or you teach teams to degrade quietly.
The fraud list, banned in writing: redefining the SLO mid-window (changes only at rollover, once per quarter, written reason); moving the window; post-hoc exclusions ("that was DNS"); counting hypotheticals. If DNS outages are frequent enough to want excluded, that's a design finding.
The weekly line in ops review: remaining %, state, burn trend, one decision the state caused. GREEN four weeks running with zero decisions = SLO too loose, tighten it until green requires care. RED three weeks straight = the reliability work keeps losing to features, and that fight belongs in planning.
Worked example: checkout API, 40.3-minute budget. Week one, a pool change burns 22 minutes - AMBER; the risky queue rework moves to the front of the week. Week two, config drift burns 18 more - RED; feature work pauses four days while two engineers ship a queue-depth alert (MTTD 31 to 9 minutes) and a canary stage. Week three, budget recovers past 20%, roadmap resumes. The counter-example is just as real: a team with a 99.99% SLO on a tier that can't fund it blows the budget monthly and concludes budgets are theater. The fix was honesty, not discipline - 99.5% (3.6 hours they could actually keep).
The full policy - the four states with named deciders, the spend rules, the fraud list, the tighten-the-SLO rule - lives on my ops-notes site: Error Budget Policy Template.
Top comments (0)