The instinct with reliability is to aim for none: zero downtime, zero failed requests, zero incidents. It sounds responsible, but it’s the wrong target, and pursuing it produces worse outcomes than accepting a defined amount of failure. The reason is that the last fraction of reliability is enormously expensive, the users can’t tell the difference between 99.9% and 99.99% most of the time, and the effort spent chasing those last nines is effort not spent on features, performance, or the recovery paths that actually matter when something breaks.

An error budget makes this tradeoff explicit. You pick a reliability target — say 99.9% of requests succeed over a month — and the remaining 0.1% is a budget you’re allowed to spend. It’s not a failure to have some errors; it’s the plan. The budget converts an open-ended, emotionally charged question (“is this reliable enough?”) into an accounting one (“how much of the budget is left?”). That conversion is the whole point. When reliability is a feeling, every deployment becomes an argument between the person who wants to ship and the person who wants to be safe. When it’s a budget, the number decides.

The mechanism works because it aligns incentives that are otherwise in tension. A team that ships fast tends to break things; a team that never breaks things tends to ship slowly. The error budget gives both sides a shared currency. If the budget is healthy — plenty of reliability left this month — the team can take risks: ship the ambitious change, run the migration, deploy on a Friday. If the budget is exhausted — too many incidents already this month — the team stops shipping risky changes and spends its effort on stability until the budget refills. Nobody has to win the argument, because the budget already settled it.

What makes this hard in practice is the discipline to actually stop when the budget is gone. The temptation, when you’ve burned through the month’s budget in the first two weeks, is to keep shipping anyway because the roadmap doesn’t care about your error budget. But shipping through an exhausted budget defeats the purpose — it turns the budget back into a number people ignore, which is the same as not having one. The budget only works if blowing it has a consequence, and the consequence has to be real enough that the team feels it: a freeze on new features, a mandatory focus on reliability work, a conversation with whoever owns the roadmap about why the target keeps getting missed.

The deeper value of the error budget is that it forces you to decide what reliability is worth before you’re in a crisis. Setting the target is a negotiation between the people who want the product to move fast and the people who need it to stay up, and doing that negotiation in advance — when nobody’s system is on fire and nobody’s judgment is clouded by an active incident — produces a saner answer than deciding in the moment. The number you pick encodes a real decision about how much failure the product can tolerate, and having made that decision deliberately is worth more than the specific number you land on.