Google & the Error-Budget Policy

This page is a different story from What Is SRE?. That page covered where SRE came from — Ben Treynor Sloss, 2003, seven engineers pointed at google.com. This page covers something narrower and more mechanical: what Google's own SRE organization actually does, in writing, the moment a service's error budget hits zero. The source is Google's own published material — the freely available Site Reliability Engineering book (2016) and its companion Site Reliability Workbook (2018) — and this page sticks closely to what those books say the mechanism is for, while deliberately hedging any specific number or exact phrase that isn't something you can go verify in the source text yourself.

Where this case actually comes from

☺ Like you're 10: Two real, free books — not a rumor, not a conference talk half-remembered — and this page tells you exactly which one said what.

The error budget as a concept was introduced in Chapter 3, "Embracing Risk," of Site Reliability Engineering: How Google Runs Production Systems (O'Reilly, 2016), edited by Betsy Beyer, Chris Jones, Jennifer Petoff, and Niall Richard Murphy, with that specific chapter credited to Marc Alvidrez. Google published the full text for free at sre.google/sre-book under a Creative Commons Attribution-NoDerivatives license, which is why this page can cite it directly rather than relying on secondhand summaries. Two years later, the follow-up Site Reliability Workbook (2018) — also free, also from Google — went further and worked through what an actual, written error-budget policy looks like end to end: SLI and SLO definitions, the budget calculation, and a section explicitly laying out consequences once the budget runs out. That second book is the more operationally useful of the two for this page's purpose, because Chapter 3 of the original book explains why error budgets exist; the Workbook's worked example is closer to what the document on file actually says.

One thing this page will not do is invent specific SLO percentages or budget-freeze thresholds and attribute them to a named, real Google service like Search or Gmail. Google's public books discuss the mechanism in detail and use illustrative, sometimes hypothetical services to demonstrate it — they don't publish the live SLO numbers for their production services, and treating an invented figure as if it were Google's actual internal number would misrepresent the source. Where this page gives a specific number, it's either a general arithmetic example already established on SLIs, SLOs & error budgets, or it's explicitly marked illustrative.

The problem an error budget was built to solve

☺ Like you're 10: Without a shared number, "was this outage bad enough to slow down for?" turns into a political fight every single time — the budget ends that fight before it starts.

Chapter 3's own framing of the problem is organizational before it's technical. Product development teams are rewarded for shipping — new features, faster iteration, more users. SRE teams are rewarded for stability — fewer pages, fewer outages, a system that stays up. Left alone, those two incentive structures point in opposite directions, and every individual launch decision risks becoming a fresh negotiation fought on vibes: is this outage bad enough that we should have caught it, or is the team asking for reliability work just being risk-averse? Google's own engineers have described "100%" as close to the wrong target for almost any real service — not because reliability doesn't matter, but because the last fraction of a percent above what users can actually perceive costs disproportionately more engineering effort than everything before it, effort that could otherwise go toward features users do notice.

The error budget resolves that fight by converting it into arithmetic instead of politics. Once Product and SRE jointly agree on an SLO, the gap between that SLO and 100% stops being an aspiration and becomes a real, spendable quantity — see SLIs, SLOs & error budgets for exactly how that quantity gets computed. Product development can spend it on launch velocity, an aggressive migration, or a chaos experiment; SRE can veto nothing that stays inside it. What changes at exhaustion isn't a value judgment about whose fault the outage was — it's a number crossing a pre-agreed line, and that's the entire point: the argument about whether to slow down was already settled, in writing, before anyone was angry about a specific incident.

Forming an error-budget policy: what actually gets written down

☺ Like you're 10: The allowance rule has to be written down and agreed to by both sides before anyone's tempted to spend past it — not improvised in the moment.

The Workbook's worked example makes a point this page wants to preserve carefully: an error-budget policy is a real document, agreed in advance, not an informal understanding SRE enforces at its own discretion. The shape of that document, as the Workbook lays it out, has a handful of recurring parts:

Notice what's absent from that list: nothing in a real error-budget policy says "SRE decides case by case whether this outage counts." The whole design goal is to remove that judgment call from the moment of crisis and make it instead in a calmer moment, in writing, before anyone's launch is actually on the line.

What "the budget is spent" actually triggers

☺ Like you're 10: Hitting zero doesn't mean nothing ships — it means only the launches that can wait actually do wait, while genuine emergencies still go out the door.

The consequence Google's books describe, and the one this course's own SLIs, SLOs & error budgets page already introduced in miniature, is a freeze: once a service's error budget is exhausted before its measurement window closes, new feature launches for that service stop until either the budget recovers as the window rolls forward, or the team earns it back by fixing whatever burned it. What a freeze is not, in any credible telling of this mechanism, is a freeze on everything. Two categories routinely stay exempt, because refusing them would make the reliability story worse, not better:

• Fixes for the incident that caused the burn. If a bad rollout is what exhausted the budget, blocking the rollback that fixes it would be self-defeating — the freeze targets new risk, not the repair of existing risk.
• Security and compliance-critical changes. A freeze that blocks a patch for an actively exploited vulnerability trades one kind of risk for a much worse one; a well-formed policy says so explicitly rather than leaving it to be argued in the moment.

Everything else on the "was going to ship soon" list — a new feature, an aggressive migration, an experiment that adds risk without addressing the thing that's currently broken — waits. That's the mechanism doing exactly what it was built to do: convert "should we slow down" from a debate into a fact that was already decided.

The negotiation: how Product and SRE actually resolve a freeze

☺ Like you're 10: A freeze isn't the end of the conversation — it's the start of a specific, pre-agreed conversation instead of an open-ended argument.

This is the part that doesn't make it into most secondhand summaries of error budgets, and it's the part this page's brief specifically asked for. A freeze doesn't mean Product's launch is dead — it means the default has flipped from "ship" to "don't," and the burden has shifted onto whoever wants to override that default to make a specific case. In practice, per the shape both books describe, that conversation tends to go one of three ways:

• Pay the budget down. Product and SRE agree the fastest path back to shipping is fixing whatever caused the burn — a flaky dependency, an under-tested rollout process, a capacity shortfall. This is usually the preferred outcome, because it improves the actual service rather than just working around the freeze.
• Request a scoped exception. If a launch is genuinely time-critical — a contractual deadline, a regulatory date — Product can ask for an exception. The policy's own escalation rules decide who's allowed to grant one, and a well-formed policy keeps that person above both teams so the exception isn't SRE quietly waiving its own rule under pressure.
• Escalate the SLO itself. If a service blows through its budget nearly every window, that's not necessarily a reliability failure — it can be a sign the SLO was set tighter than the business actually needs. Both books treat this as a legitimate outcome, not a defeat: the target gets renegotiated with the same rigor it was set with in the first place.

Why one global policy doesn't work for shared infrastructure

☺ Like you're 10: A shared pantry can't have one "how much can you take" rule if one kid needs a snack every hour and another only bakes once a month — the rule has to fit the actual user.

Chapter 3 draws a distinction that matters more the deeper a service sits in a stack: a consumer-facing service usually has one dominant way it's used, so one SLO reasonably captures what its users need. A shared internal infrastructure service — a storage layer, a queue, an internal API — routinely serves multiple internal customers with genuinely different risk tolerances at once: one team building an interactive, latency-sensitive product on top of it, another running an overnight batch pipeline that cares far more about eventual completeness than millisecond latency. A single blanket SLO tuned for the interactive customer would force the infrastructure team to over-engineer for the batch customer's needs too, burning effort nobody asked for; tuned for the batch customer, it would silently fail the interactive one.

The practical fix the book describes is per-class or per-customer targets rather than one number for the whole service — sometimes expressed as different priority tiers of traffic against the same backend, each with its own budget and its own consequences at exhaustion. This is a genuinely harder policy to write and govern than a single-service freeze, and it's one more reason this page doesn't pretend to reproduce Google's actual internal numbers: the real complexity here is organizational as much as it is arithmetic, and the specifics are exactly the part that's least likely to be published.

A worked, illustrative walkthrough

☺ Like you're 10: A made-up example, clearly labeled as made up, so you can see the shape without anyone pretending it's a real Google number.

The excerpt below is this course's own illustrative construction — modeled after the shape both books describe, not a reproduction of any real policy document. Use it to see how the pieces from the table above actually read once assembled, not as a template to copy verbatim into a real org without adjusting it to that org's actual risk tolerance.

Service:        checkout-api  (illustrative example — not a real Google service)
SLO:            99.9% successful requests, trailing 28-day window
Error budget:   0.1% of valid requests, ≈ 40 minutes-equivalent of failed traffic

Budget state                    → Policy response
──────────────────────────────────────────────────────────────────────
0–50% burned                    → normal release velocity, no restriction
50–100% burned                  → soft warning to Product's tech lead;
                                   SRE flags newly risky changes for review
100% burned (exhausted)         → hard freeze: new feature launches halted;
                                   config & feature-flag changes need SRE
                                   sign-off; active-incident fixes and
                                   security patches are explicitly exempt
Exhausted 2+ consecutive windows → SLO escalated to joint leadership for
                                   renegotiation, not just repeatedly excused

Read the bottom row carefully — it's the detail most casual retellings of "Google invented error budgets" leave out entirely. The mechanism isn't just a launch gate; it has a built-in escape hatch for the possibility that the target itself, not the team, is the thing that's wrong.

What Google says this actually bought them

☺ Like you're 10: Less arguing, more building — because the rule already answered the question before the argument could get personal.

As with any org's account of its own practices, treat the following as Google's stated rationale rather than an independently audited result — there's no external study measuring how many launch disputes an error budget actually prevented. What both books do claim, consistently, is a shift in the shape of the conversation: instead of every outage triggering a fresh, personal argument about whether it was "bad enough" to slow down for, the argument gets settled once, in advance, by people who aren't currently angry about a specific incident. That reframing does two things at once. It gives SRE a legitimate, pre-agreed claim on the team's priorities when reliability work is genuinely warranted — rather than losing that argument every sprint to the next feature. And it gives Product a real, quantified amount of risk they're explicitly permitted to spend without asking permission each time, which is a genuine grant of autonomy, not just a constraint with a friendlier name.

What to steal for your own team

☺ Like you're 10: You don't need Google's size to copy the habit — write the rule down before you need it, and mean it when the number says stop.

• Write the policy before the budget is ever spent. A rule invented in the middle of the incident that burned the budget isn't a policy, it's a rationalization — agree on consequences while everyone's calm and nobody's launch is on the line.
• Name the exemptions explicitly, in advance. Decide now, not during the freeze, that active-incident fixes and security patches still ship. Leaving that ambiguous just moves the argument you were trying to eliminate one step later.
• Put exception authority above both teams. If SRE alone can both enforce the freeze and waive it, the freeze has no independent teeth. The Workbook's own instinct — someone with authority over both orgs signs off on exceptions — is worth copying at almost any org size.
• Build in a path to renegotiate the SLO, not just to excuse it. A service that blows its budget every window isn't proof the team is failing; it may be proof the target was set wrong. Treat repeated exhaustion as a signal to re-examine the number, the way capacity planning & performance treats a chronically saturated system as a signal to re-plan, not just push harder.
• Segment shared infrastructure by customer class, not by one blanket target. If your platform serves both latency-sensitive and throughput-sensitive internal customers off the same backend, one SLO will under-serve one of them — plan per-class budgets from the start rather than retrofitting them after the first fight.

Honest caveats: what doesn't transfer

☺ Like you're 10: This story comes from two real, generous, free books — but even generous books don't publish every internal number, and this page won't pretend they do.

• This page paraphrases; it doesn't quote a hidden internal document. Google's books explain the mechanism and work through illustrative examples — they are not a leaked copy of a specific service's actual, current error-budget policy. Treat every mechanic on this page as "the shape Google's published material describes," and go read sre.google/sre-book and the Workbook directly for the authoritative wording before citing anything from here as a verbatim source.
• Specific numbers here are illustrative, not Google's real figures. The 99.9%/40-minute example above is this course's own construction, built the same way the arithmetic on SLIs, SLOs & error budgets was — it is not a disclosed Google SLO for any named service.
• The mechanism assumes organizational leverage this page can't guarantee you have. A freeze only has teeth if leadership actually backs the escalation path when a VP wants their pet launch to ship anyway. A written policy with no enforcement behind it is worse than no policy — it creates the appearance of rigor while behaving exactly like the ad hoc negotiation it was meant to replace.
• Google's own practice has surely evolved since 2016 and 2018. Both source books are snapshots of practice at specific points in time, at one company. Treat the mechanism — SLI, SLO, budget, written consequences, escalation authority, a path to renegotiate — as the durable, transferable part, and treat any specific figure as something to verify against current, primary sources rather than assume is still current.

Where this connects in the course

☺ Like you're 10: One real company's written rule touches half this course — read whichever link matches what you're actually building.

The arithmetic this whole policy is built on top of is SLIs, SLOs & error budgets — read that first if the 100%-minus-SLO calculation above didn't already make sense. How fast a service burns its budget, and how urgently that should page someone, is Multi-Window, Multi-Burn-Rate Alerting. The launch-gate half of this story — deciding whether a service is even allowed to accept new risk in the first place — is Production Readiness Reviews. The organizational question of who has standing to grant an exception, and how Product and SRE are structured relative to each other in the first place, is SRE Team Topologies, and the cost side of "should we spend engineering effort chasing another nine" is Reliability Economics. For what happens once a freeze-triggering incident actually gets written up afterward, see postmortems & blameless culture and this course's own worked incident in Case study: an outage post-mortem. And for how two other real companies handled the people side of incidents — not the budget math, the culture — see Etsy & the Origin of Blameless Postmortems and Cloudflare's Public Postmortem Culture.