Google SRE: Error Budgets as a Negotiation Device
also called SRE Error Budget
Google resolved the standing conflict between shipping speed and reliability by giving both sides a shared number and a pre-agreed consequence.
The problem
Product teams want to ship. Operations teams want stability. The conflict is structural, not personal — each is optimising for what they are measured on — and it is normally resolved by whoever has more organisational power in that quarter.
The resulting dynamics are familiar: reliability work is perpetually deprioritised until an outage, after which it is over-prioritised, and neither state is a decision.
What they did
Google's SRE practice frames it as an error budget. If the availability objective is 99.9%, then 0.1% of unreliability is not a failure — it is a budget the product team is entitled to spend on shipping changes.
The mechanism is the pre-agreed policy attached to it. While the budget is healthy, ship freely. When it is exhausted, feature releases pause and engineering effort moves to reliability until it recovers.
That converts a recurring argument into an automatic, evidence-based decision. Nobody has to win.
The half that gets forgotten
A consistently unspent budget is also a signal — it means the target is too conservative and the organisation is buying reliability nobody asked for. That direction is as important as the other, and it is the one that rarely gets acted on. Over-reliability is a real cost: it shows up as slow delivery and over-engineered systems.
The preconditions
The SLO must measure something users actually experience. Freezing feature work because a badly chosen indicator dipped destroys the mechanism's credibility in one cycle.
And product leadership must genuinely agree to the policy in advance. A policy overridden the first time it binds is worse than none, because it establishes that the mechanism is decorative.
The transferable lesson
An SLO without a policy is a dashboard. The number is not the innovation; the pre-agreed consequence is. Agree it when the discussion is hypothetical and reasonable, not during the incident review with a launch scheduled.
And set targets from the business consequence, not from a desire for more nines. Each additional nine is roughly an order of magnitude more expensive, and for most systems the fourth one buys nothing a customer notices.