Somewhere there's a VP who thinks the error budget solved the fight between product and reliability. The budget was supposed to be the thing that made the tradeoff explicit — burn it, and you slow down; stay under it, and you ship. Clean. Quantitative. No more Friday-afternoon shouting matches about whether this release is "safe enough."
It didn't end the argument. It just moved the argument from the release review to the spreadsheet where the budget itself gets defined, which is a worse room to have it in, because nobody's paged from that room at 3am.
The Budget Is Only as Honest as the SLO Underneath It
An error budget is a derivative number. It inherits whatever's wrong with the SLO it's measured against. If the SLO was set by someone estimating what sounded defensible in a planning doc rather than what users actually tolerate, the budget built on top of it is just institutionalized guesswork wearing a math costume.
I've watched teams treat a blown error budget as an automatic, mechanical signal — stop shipping, full stop — without ever revisiting whether the SLO that triggered it reflects anything real. The budget becomes a ritual object. You genuflect to it in the planning meeting, then quietly ship anyway because the feature has a launch date attached to someone's performance review. The spreadsheet says one thing; the calendar says another. Guess which one wins.
This isn't an argument against error budgets. It's an argument against treating the number as more trustworthy than the judgment that produced it. A budget is a conversation starter, not a verdict. Teams that use it well keep asking whether the target underneath is still the right target — not just whether they're under or over it this quarter.
Who Actually Gets to Spend the Budget
The harder failure mode shows up in who controls the burn. On paper, error budgets are supposed to give reliability a seat at the table: burn too much, and engineering gets to say no to the roadmap for a while. In practice, the people deciding how fast to burn and the people who get paged when it's gone are rarely the same people in the same room at the same time.
Product owns the roadmap. SRE owns the budget math. Somewhere between those two groups the actual decision — ship the risky thing now, or wait — gets made by whoever has more leverage that quarter, and the budget becomes evidence for whichever side is arguing, rather than the referee it was designed to be. A reliability team with no organizational weight can point at a blown budget all day; if nobody above them treats that as a stop signal, it's just a very precise way of being ignored.
The teams I trust on this are the ones who've made the budget's authority explicit before the fight happens — not during it. Who gets to halt releases when the budget's gone, and does that person actually have the standing to make it stick? If the answer gets negotiated fresh every time the budget runs dry, you don't have an error budget policy. You have a scoreboard that everyone agrees to read differently depending on what they want that week.
What Actually Changes Behavior
The honest version of an error budget does two unglamorous things well. First, it forces someone to write down, in advance, what "good enough" means in numbers instead of vibes — and it forces that number to get revisited instead of fossilizing. Second, it attaches a real consequence to crossing the line, decided by someone with the authority to enforce it before the quarter starts, not negotiated in the moment by whoever's most persuasive in the incident channel.
Neither of those things is a formula. They're organizational commitments dressed up as math, which is fine, as long as everyone remembers which part is the math and which part is the commitment. The number tells you where you stand. It's never going to tell you who has to listen.
If your team runs on error budgets, the useful exercise isn't recalculating the burn rate. It's asking who actually had to change their behavior the last time the budget ran out — and whether that person was the one who set the target in the first place.