Every engineering team has the same standoff: product wants to ship fast, ops wants to stay up, and the two argue about it forever with no way to settle it. Google's SRE teams solved this with a deceptively simple idea. Turn reliability into a budget. Once "how reliable should we be" is a number both sides agreed on, the fight mostly disappears.
Key Takeaways
- An SLO (service level objective) is a target for reliability, say 99.9% availability (Google SRE).
- An error budget is 1 minus the SLO: a 99.9% SLO gives a 0.1% budget of allowed failure (Google SRE).
- While budget remains, ship freely; when it's spent, releases halt until reliability recovers (Google SRE).
- It converts an endless argument into a data-driven control loop.
The Idea
The SRE approach starts by picking a Service Level Objective: a concrete reliability target, like "99.9% of requests succeed over 28 days" (Google SRE on SLOs). That number is a decision, not a law of nature. 100% is the wrong target, it's impossibly expensive and users can't tell the difference between 100% and 99.99% anyway. So you pick a number that's good enough for users and affordable for you.
The error budget is what's left over: one minus the SLO (Google SRE, Embracing Risk). A 99.9% SLO means you're allowed 0.1% failure. For a service handling a million requests over four weeks, that's a budget of a thousand errors you're permitted to spend. Downtime, failed deploys, latency spikes, they all draw down the same budget.
The Control Loop
Here's where it stops being an accounting trick and becomes a way to run engineering (Google SRE error-budget policy). While there's budget left, the team ships as fast as it wants; risk is affordable, because you have room to spend. When the budget runs out, the policy flips: releases halt (except security and critical fixes) and the team focuses on reliability until the service is back within its SLO. The budget decides whether it's a "ship features" week or a "fix reliability" week, instead of a person's opinion.
| Situation | What the budget says |
|---|---|
| Budget healthy | Ship features, take risks |
| Budget running low | Slow down, add testing |
| Budget exhausted | Halt releases, fix reliability |
Why It Works
The magic is incentive alignment. Without an error budget, product and ops have opposing goals and argue endlessly. With one, they share a single number and a single rule. Product stops treating reliability as ops' problem, because burning the budget on a sloppy release means a feature freeze they'll feel. Ops stops treating every risk as unacceptable, because there's explicit room to spend. The budget makes the tradeoff visible and shared, which is the whole point.
A Concrete Version
A team keeps fighting: the PM pushes to ship, the on-call engineer resists because things keep breaking, and every release is a negotiation. They set a 99.9% SLO. For a few weeks reliability is fine, so features ship without argument, nobody has to relitigate risk. Then a bad release burns most of the month's budget in two days of incidents. The policy kicks in automatically: no new features until they're back within SLO. The PM, who now has skin in the reliability game, is suddenly very interested in better testing. No one had to win an argument; the budget settled it.
The Honest Counterpoint
Error budgets are a heavyweight practice, and a three-person startup with ten users does not need formal SLOs and budget policies yet. Setting them up requires real measurement (you need reliable metrics on what "success" means for your service) and organizational buy-in to actually honor the halt-releases rule, which is worthless if leadership overrides it the first time a deadline looms. The idea scales down, though: even informally, picking a reliability bar and agreeing what happens when you breach it beats arguing case by case. Adopt the full machinery when reliability genuinely matters to your users and revenue.
What This Means for Teams
Error budgets are part of the reliability discipline that separates mature engineering orgs, alongside fast incident recovery and the delivery health that DORA metrics track. Engineers who've worked in SRE cultures bring this thinking with them, and setting up sane SLOs is often one of the highest-impact things a senior hire can do for a team drowning in the features-versus-uptime fight. See available engineers.
Frequently Asked Questions
What is an error budget?
The amount of unreliability a service is allowed, defined as one minus its SLO. A 99.9% availability target gives a 0.1% error budget, the failure you can "spend" before releases halt.
What is an SLO?
A service level objective: a concrete reliability target, like 99.9% of requests succeeding over a month. It's a deliberate choice about how reliable the service needs to be, since 100% is impractically expensive.
How do error budgets end the features-vs-reliability fight?
They replace opinion with a shared number and rule. While budget remains, the team ships; when it's spent, releases pause to fix reliability. Both sides share the same incentive.
Do small startups need error budgets?
Not the full formal machinery early on. But even informally agreeing on a reliability bar and what happens when you breach it beats arguing every release case by case.
The Bottom Line
The endless fight between shipping and staying up has a clean solution: make reliability a budget. Set an SLO, treat one minus it as the failure you're allowed to spend, and let the budget decide when to ship and when to fix. It aligns product and ops around one number and turns a standing argument into a control loop.
Roberto Espinoza is CEO of Ruzora, which helps US startups hire pre-vetted senior LATAM engineers in 72 hours. See available engineers.
