Core Thesis: Google designed the “error budget” to solve a specific problem: ending the eternal war between developers (who want to ship fast) and operations (who want stability). For that, it works well. However, the tech industry has since misused the error budget, turning it into a stand-in for understanding system reliability. But an error budget is just a backward-looking ledger. It acts as an emergency brake that only pulls after the crash. To build truly resilient systems, organizations must graduate from simple accounting to Situational Intelligence—the ability to understand context, anticipate risks, and adapt in real time.
Highlights
- Google created error budgets as a negotiation tool to balance release speed between developers and operators, not as a comprehensive model of distributed system health.
- An error ledger is backward-looking and cannot differentiate between a fixed bug, an active cascading failure, or an impending saturation cliff with zero failures so far.
- Using error budgets only for deployment freezes assumes code changes cause all incidents, ignoring traffic spikes, expired certificates, and third-party outages.
- Using error counts as reliability proxies shifts engineering focus from system understanding to accounting negotiations—reclassifications, exclusions, and freeze exemptions.
- Resilient operations require moving past reactive burn rates to real-time context: detecting operational drift before limits breach, projecting system trajectory, and expanding mitigations beyond the release brake.
A Good Negotiating Tool
By agreeing on a Service Level Objective (SLO), developers and operations teams turned a subjective argument into simple arithmetic. The SLO defines acceptable unreliability. The gap between perfection and that threshold forms a “budget.” When the budget is spent, feature releases freeze, and teams focus on reliability. This was a big leap forward. It gave teams conflicting incentives a shared, objective metric. However, it only works under specific conditions:
- The goals must center on user experience.
- System changes (deployments) must be the primary source of risk.
- The organization must actually enforce the rules when the budget runs out.
The issue emerged when the industry advanced this idea.
A tool meant to resolve disputes over release velocity became the primary way we describe reliability. We ceased asking whether we control the system and began asking whether we have used our allowance.
The Blind Spots of the Ledger
Error budgets appeal to management because they condense vast operational complexity into one figure. Yet this same simplicity makes them poor indicators of actual system health. A balance sheet removes context.
With a 1,000-error allowance, an error budget views these three scenarios differently than an engineer does:
- [A] The Resolved Glitch: A bad deployment causes 250 errors before being rolled back and fixed. The budget is 25% spent. Reality: The system is perfectly stable and safe to move forward.
- [B] The Active Cascade: A degraded database causes 250 errors, queues are rapidly backing up, and retry storms are compounding the load. The budget is also 25% spent. Reality: You are in the middle of an escalating crisis.
- [C] The Impending Cliff: Server memory is at 99%, pushing the system to the brink of collapse, but zero requests have actually failed yet. The budget is 0% spent (Perfectly Green). Reality: Catastrophic failure is imminent.
To an error budget, Scenarios A and B appear the same, while Scenario C is flawless. Error budgets activate only after a safety line is crossed. They record past damage but lack insight into direction, mechanics, or hidden risks.
An Emergency Brake Wired to a Rearview Mirror
If you view an error budget as a control system, it functions like an automatic emergency brake linked to a collision detector: it only realizes you’ve lost control after you’ve hit something, and its only response is to hit the brakes.
This sets up a dangerous dynamic due to two fundamental limitations:
- It Only Has One Lever: In systems theory (Ashby’s Law), a controller must match a problem’s complexity with its responses. A release policy offers three fixed choices: proceed, slow down, or freeze. This approach suits a faulty code change. However, an expiring certificate, a sudden traffic surge, or a third-party disruption may arise. Freezing deployments will not resolve these issues; instead, they often demand quicker releases to deploy a fix.
- It is Blind to the Inside of the System: Good observability (Kalman’s Observability) means you can deduce what’s happening inside a system based on its external outputs. An error budget collapses completely different internal realities—a contained defect vs. a cascading network failure—into the exact same number.
Goodhart’s Law and the Cognitive Cost
A psychological idea known as attribute substitution suggests that people often replace a complex question, such as “Do we understand how our system is behaving right now?”, with a simpler one like “How much error budget is left?”
When an organization treats the error count as the definitive model of reality, Goodhart’s Law emerges: once a metric becomes a target, it loses its value as a reliable measure. Engineers shift from managing the system to managing the math. Meetings intended for system architecture become disputes over accounting rules: Which errors might be reclassified? Which dependencies are exempt? Can we exclude this maintenance window? The organization gains a illusion of control, while its capacity to notice unfamiliar conditions and anticipate shifts gradually weakens.
The Alternative: Situational Intelligence
Reliability cannot be achieved through static rules and retroactive postmortems, where lessons are frozen into documents while the live system blindly continues. We need to organize operations around Situational Intelligence—the ability of both the system and the humans running it to recognize context, project what will happen next, and adapt.
A truly intelligent operational architecture replaces reactive metrics with an active control system:
- Contextualize at the source: Don’t export raw error counts to be pieced together later. Interpret signals where they originate.
- Live modeling, not dead documents: Instead of archiving lessons in postmortems, the system should maintain a continuous, living model of operational states that updates as conditions change.
- Continuous feedback: Every intervention taken (e.g., shedding load, shifting traffic, scaling) must instantly feed back into the system to refine how it handles similar situations in the future.
None of this means error budgets are useless. They are highly valuable for their original purpose: negotiating release risk when user experience is the focus, and when code changes are the primary danger. But they must be paired with situational intelligence. An SLO is simply a promise you make to your users. An error budget is just an assessment of how well you kept that promise yesterday. Situational intelligence is the actual work of keeping the promise today.
A QUESTIONNAIRE OPERATIONS
To gauge whether your organization prioritizes accounting over engineering, ask these seven questions:
- Can your system characterize the exact situation it is in right now?
- Can it detect a meaningful, dangerous change before a failure threshold is breached?
- Can it recognize when it is in an unfamiliar situation and trigger a discovery process?
- Can it project where the current situation is heading, and state its level of uncertainty?
- Does it offer a wide menu of available interventions, rather than just “freeze releases”?
- Can it evaluate whether a fix actually worked, and automatically learn from it for next time?
- Does your organization’s true understanding reside in static dashboards and documents or in the running system?