Error budgets: stop arguing, start subtracting

Every engineering org runs the same fight on a loop. Product wants to ship faster; the people who carry the pager want to stop breaking things. Both are right, which is exactly why the argument never ends — there's no shared unit to settle it in. One side measures success in features shipped, the other in incidents avoided, and you can't trade between currencies that don't convert. So the fight gets re-litigated every quarter, won by whoever has more political capital that week, and resolved by nobody.

The error budget is the trick that dissolves the argument instead of winning it. It takes 'how much reliability is enough?' — an unanswerable values question — and turns it into a finite number both sides agree to up front. After that, you don't argue about whether to slow down. You look at how much budget is left and subtract.

Reliability is a quantity, not a virtue

The first move is the one that feels wrong: admit you don't want 100% reliability. You never did. The last fraction of a nine costs exponentially more than the one before it, your users can't perceive it over the noise of their own flaky networks, and chasing it means shipping nothing. So you pick a target you can actually defend — 99.9%, say — and the instant you do, you've quietly admitted that 0.1% of the time, failure is acceptable. Not a tragedy. Acceptable. That admission is the whole foundation.

Because once failure has a permitted amount, that amount is a budget. A 99.9% monthly objective allows roughly forty-three minutes of not-working per month, and those forty-three minutes are yours to spend. Spend them on the inherent risk of deploying often, on a bold migration, on shipping the feature before every edge case is gilded. Reliability stops being a virtue you're failing to live up to and becomes a resource you're choosing how to allocate, which is a thing engineers and product people both know how to reason about.

The policy decides, so people don't have to

Here's the part that actually ends the fight: you write down what happens at the boundaries before you reach them, and then you obey the policy instead of your mood. Budget remaining? Ship aggressively — that's what the budget is for, and hoarding it is as wasteful as overspending it. Budget exhausted? The next work, full stop, is reliability — bug fixes, hardening, paying down whatever burned the budget — until it refills. No exceptions argued case by case, because the case was argued once, in advance, when nobody was under pressure.

What this buys you is depersonalization, and that's worth more than it sounds. When the budget runs out, it isn't the SRE being a blocker or the PM being reckless — it's a number both of them agreed to, doing the thing they agreed it would do. The decision to slow down stops being a confrontation between two people and becomes a consequence of a shared rule. Nobody has to pull rank, nobody has to win the meeting, and the person delivering the bad news is a dashboard instead of a colleague.

A budget is permission to take risks

The reframe that surprises reliability-minded engineers is that an error budget is not a stick — it's permission. A team with budget in the bank has explicit, pre-granted license to do the risky, fast, valuable things that a zero-tolerance culture forbids. Deploy on a Friday. Run the experiment that might tip over. Ship the rewrite. The budget exists precisely so you can spend it, and a team that ends every month with a full budget isn't being virtuous; it's being too cautious, leaving velocity on the table it was allowed to use.

This flips the usual relationship between reliability and speed from adversarial to allied. The objective isn't to minimize failures — it's to spend the allowed failures on the most valuable risks. That turns the reliability target into something product actively wants to defend, because the budget is the thing funding their ability to move fast. You stop having a stability team and a velocity team fighting over the wheel and start having one team deciding, together, how to spend a shared allowance on the bets most worth making.

It only works on honest numbers

The error budget has two failure modes, and both come from lying with numbers. The first is choosing a target nobody believes — slapping 99.99% on a service because it sounds impressive, when you have neither the architecture nor the intention to hit it. Now the budget is always blown, the policy is always demanding a reliability freeze nobody honors, and the whole mechanism gets ignored within a month. The target has to be one you'd actually defend out loud, or the budget built on it is fiction.

The second failure mode is not measuring it for real. An error budget computed from a number someone estimates, or from a metric that quietly excludes the failures that embarrass you, is worse than no budget at all, because it launders gut feelings as data. The budget has to be drawn from real events — actual downtime, actual failed requests, actual recovery time — recorded somewhere trustworthy. If the inputs are negotiable, the budget is just the old argument with extra decimal places, and you've added math without adding honesty.

Grounding the budget in the record of the work

All of which means the error budget lives or dies on the same thing every honest metric does: a real, unfudgeable record of what actually happened. You need incidents that are logged when they start and end, deploys that are recorded when they ship, and failures that are counted whether or not they're convenient — and you need all of it tied back to the work that caused it, so 'we burned half the budget this month' comes with a thread you can pull to the changes behind it. A budget you can't trace is a budget you'll eventually rationalize away.

That's the connection between an error budget and the boring infrastructure of a work platform. When deploy and incident events in Planoda link back to the issues they touched, and the audit log records each one immutably, the budget stops being a number someone maintains in a spreadsheet and becomes a readout of the actual record — minutes of failure this period, the incidents that spent them, the changes those incidents trace to. The argument you used to have every quarter doesn't need a referee anymore. It just needs the subtraction, done against numbers nobody can quietly edit.