Every engineering team has the same tug-of-war: product wants to ship faster, ops wants to keep it stable. It usually plays out as an argument based on gut feeling. Error budgets end that argument by replacing opinions with a number — one of the most elegant ideas to come out of SRE.
What an error budget is
An error budget is simply the flip side of your reliability target (SLO). If your SLO says you'll be reliable 99.9% of the time, then you're allowed to be unreliable 0.1% of the time. That 0.1% is your error budget — a permitted, quantified amount of failure.
SLO = 99.9% → error budget = 0.1%
The reframe is everything: failure isn't something to avoid at all costs. It's a budget to spend — and spending it is fine, even healthy.
How to calculate it
Turn the percentage into real time over a window:
- SLO 99.9% over 30 days → error budget = 0.1% of 43,200 minutes = ~43 minutes of allowed failure that month.
- SLO 99.99% → ~4 minutes/month — a much tighter budget.
| SLO | Error budget / month |
|---|---|
| 99% | ~7h 18m |
| 99.9% | ~43m |
| 99.99% | ~4m |
(More on the maths in what is 99.9% uptime.)
How it changes the way you work
This is where error budgets shine. Instead of arguing, you look at the gauge:
| Budget status | What it tells you |
|---|---|
| Plenty left | Ship boldly — take risks, run experiments |
| Running low | Slow down — prioritise stability and fixes |
| Blown | Stop risky changes; focus on reliability |
Error budgets align incentives. Product and engineering stop fighting about feelings and start looking at the same number. "We have budget" means go; "we're out of budget" means fix things. Both sides agree because it's data, not opinion.
And here's the counter-intuitive flip side: an unspent error budget is also a signal — you're probably being too cautious, leaving speed (and features) on the table. The goal isn't zero failure; it's spending the budget wisely.
Burn rate: the early warning
The pros watch not just the budget but the burn rate — how fast you're using it up.
A high burn rate is an early alarm. If you're consuming your monthly budget 10× faster than sustainable, you'll blow the SLO long before month's end — so you alert on the burn rate, catching trouble while there's still time to act, rather than waiting until the budget is already gone.
This is a smarter way to alert than paging on every blip: page when the budget is burning dangerously fast.
Putting it into practice
- Set an SLO for a key service, measured by a real SLI.
- Derive the budget (100% minus the SLO).
- Track consumption over your window.
- Make a policy: budget left → ship; budget gone → freeze risky changes and fix reliability.
- Alert on burn rate, not just raw failures.
The bottom line
| In one line | |
|---|---|
| What | The allowed failure under your SLO (100% − SLO). |
| Reframe | Failure is a budget to spend, not to fear. |
| Use | Budget left = ship; budget gone = stabilise. |
| Burn rate | Alert when you're spending it too fast. |
Error budgets turn reliability from a feeling into a number — ending the ship-vs-stability war with shared data. Set an SLO, track the budget, and let it guide when to push and when to steady the ship.
Related: SLA vs SLO vs SLI, what is SRE?, what is 99.9% uptime?.