Error Budgets Are a Conversation, Not a Metric
Why error budgets exist, how to set one without ceremony, and what to do when you blow through it — in practice, not in theory.
Most teams I’ve seen adopt SRE concepts backwards. They pick an SLO like “99.9%” because it sounds good, stare at a dashboard, and then argue about whether an incident “counted.” The point of an error budget isn’t the percentage. It’s the conversation it forces.
What an error budget actually is
If your SLO is 99.9% available over 30 days, you get ~43 minutes of budget to be down. That 43 minutes is a spendable resource. It’s permission:
- Permission to ship risky changes
- Permission to do migrations
- Permission to take the system down for maintenance
When the budget is healthy, you should be more aggressive — ship more, freeze less. When it’s spent, you freeze non-essential change.
Setting an SLO without ceremony
- Pick the user journey that matters most (e.g. “can I serve my API”).
- Measure the last 90 days of availability as the user saw it — not your synthetic probe.
- Round down to the nearest 9 your infra can actually sustain without heroic effort.
- Document what “available” means in one sentence.
Service: payments-api
Journey: POST /charge returns 2xx within 800ms p99
Window: rolling 28d
SLO: 99.5% → budget = 5h 2m per window
Owner: @payments-oncallWhen you blow the budget
This is the part most teams get wrong. Blowing the budget is not an emergency. It’s a signal. The agreed response:
- Stop feature deploys to that service. Fixes only.
- Post-mortem the spend within one week.
- Decide: was the SLO wrong, or the system unstable? Either fix the system or relax the SLO. Don’t do neither.
Anti-patterns
- 100% SLOs. They don’t exist. Setting one tells everyone you haven’t thought about reliability honestly.
- SLOs without owners. A dashboard nobody is on call for is decoration.
- Budgets that never get spent. If you’re always at 99.99% against a 99.5% target, your target is too lax. Spend the slack shipping faster.
TL;DR
An error budget is a pre-agreed answer to “how much downtime are we okay with?” When you frame it as permission to move fast instead of a scoreboard, it stops being threatening and starts being useful.
