Error budgets are the most cited, least practiced idea in SRE. Every team has read the Google book. Every PM has been in a "this feature is critical" meeting. And every on-call engineer has stared at a burn-rate graph at 11 PM, wondering whether anyone will actually honor the freeze when the budget runs out. Here's the awkward part: error budgets only matter if they're enforced. And enforcement is a political problem, not a technical one. The budget is fine, until the quarter isn't Pick any service with a 99.9% monthly SLO. That's 43 minutes of downtime allowed per calendar month. Sounds generous. Until the auth service had a 28-minute outage on the 5th because of a bad deploy, a flaky migration ate 6 more minutes on the 15th, and a misconfigured DNS rollout burned 9 minutes on the 22nd. It's the 26th. You have zero minutes of budget left. And the product manager just pinged you asking why the payments team's new retry logic can't ship tomorrow. This is the scene that tests whether your organization actually does SRE, or just imports its vocabulary. Three policies that hold up Three policies tend to survive contact with real calendars. The third is the one most teams skip because it's uncomfortable. Green/yellow/red deploy gates, tied to the pipeline, not to a human.** Define three states based on current burn. Green (under 50% budget used) = normal velocity. Yellow (50-90%) = only backwards-compatible changes go out, no schema migrations, no rollouts that can't be instantly rolled back. Red (above 90%) = freeze for everything except P0 security fixes. Critically, the deploy pipeline reads the current burn metric and decides. No human debate at the CI gate. When the gate blocks a deploy, the engineer sees "red budget, 3 days to reset" on the PR, and they know why. **Weekly burn-rate review with engineering leadership, not just SRE.** Most teams run post-incident reviews but skip budget reviews. The difference matters. Post-incident fires are easy — something broke, fix it, move on. Budget reviews ask the harder question: *Are we shipping too fast for what the platform can absorb?* That's a velocity-vs-reliability conversation, which belongs with the EM and the product lead in the room, not with SRE alone. If engineering leadership isn't in the meeting, the answer is always "no, ship more". **A pre-committed freeze precedent.** The first time you need to actually freeze deploys, someone senior will push back. Guaranteed. Your only defense is showing them the document they signed in Q1 that said: "if the error budget hits zero, non-critical work freezes for N days until the rolling window resets". Without the pre-commitment, every freeze becomes a new political argument. What doesn't work **Making error-budget health a KPI for the SRE team.** SRE measures budget burn. Product and engineering *cause* it. If the SRE lead's bonus depends on not burning through, you've inverted the incentive — they'll push back on every feature ship, and over time, engineering will quietly route around them. The budget is a reliability contract between the product and the platform. SRE is the scorekeeper. **Expanding the SLO after you blow through the budget.** If the SLO always seems to be "within reach", it isn't a commitment. It's a forecast. Customers don't care about your forecast; they care about whether the thing works on Tuesday at 3 PM. **Treating the budget as a target to hit, not a limit to stay under.** Teams sometimes relax deploy discipline because "we have budget to burn" mid-month. That's the same logic that gets people to spend down their vacation balance on work calls. The budget is insurance against surprises — outages that *will* happen, but you can't predict. Don't burn it for convenience. The honest read Most engineering orgs adopt error budgets because the language sounds rigorous. Fewer let the numbers shape decisions. The signal that yours is real: a PM has been told "no" to a ship this quarter because the budget wouldn't cover the risk, and the PM was fine with it. If you can't remember the last time that happened, what you have is a burn-rate dashboard, not an error budget. How to start if you don't have one Don't begin by picking a target. Begin by measuring. Spend one month just publishing the weekly burn rate against a provisional 99.9% SLO and see how the team reacts. You'll probably discover one of two things. Either the service is wildly over-provisioned - you're at 99.99% without trying, and the budget is meaningless. Or the service quietly misses the target, and nobody has noticed, because alerting fires on symptoms, not on the budget. Both outcomes are informative. The first tells you to raise the SLO until it stings. The second tells you your current infra investment isn't matching your stated reliability claims, and that's a budget request with teeth. Only once you've watched the number move for a month should you wire in the gates and the freeze precedent. Otherwise, you're enforcing a poli…