Error budgets in practice: turning SLOs into decisions
An SLO only matters if it changes what you do. Here's how to calculate an error budget, spend it deliberately, and settle 'ship vs. stabilize' with data.
Plenty of teams set an SLO and then never mention it again. The error budget is what makes an SLO operational — it converts a reliability target into a spendable quantity that settles arguments about whether to ship or stabilize. Here’s how to actually use one.
The budget is just 100% minus your SLO
If your SLO is 99.9% availability over 30 days, your error budget is the other 0.1% — about 43 minutes of allowed downtime that month. That’s not a failure; it’s a budget. You’re expected to spend it. The point is to spend it on purpose.
Spend it on the things that create risk
Every risky-but-valuable activity draws down the budget: shipping features fast, running migrations, load-testing in production, chaos experiments. When there’s budget left, you have room to move quickly. The budget reframes reliability from “never break anything” to “here’s how much risk we can afford this month” — which is a far healthier conversation.
The policy: what happens when it runs out
The budget only works if breaching it triggers something automatic and pre-agreed:
- Budget remaining → ship freely; take reasonable risks.
- Budget nearly gone → slow down; prioritize reliability work; tighten review on risky changes.
- Budget exhausted → a feature freeze until you’re back within SLO, with the team’s focus shifting to stability.
Agree this policy before you need it, so an exhausted budget triggers a plan instead of a fight.
Measure the budget honestly
An error budget built on bad measurement is theater. The SLI feeding it has to reflect reality: check often enough to catch short outages, confirm from multiple regions so network blips don’t burn budget you didn’t actually spend, and count correct responses — a slow 200 or an error page with a success code should draw down the budget, because it drew down your users’ patience.
The bottom line
Error budgets turn “we should be more reliable” into a number everyone can see and a policy everyone agreed to. Calculate it from your SLO, spend it deliberately on risk, freeze when it’s gone, and measure it honestly. It’s the cleanest way to make the ship-vs-stabilize decision with data instead of opinions.
Build reliability on real signals. Explore Spectra for DevOps & SRE →
