At a Glance
Error budgets were designed to balance release velocity with reliability, but most enterprises have implemented them as observability metrics rather than enforceable governance mechanisms. Dashboards can show burn rate, yet they cannot decide when releases stop, who holds authority, or how trade-offs are resolved under pressure. This article argues that error budgets only work when they are backed by formal policy, cross-functional commitment, and operating model discipline.
Error budgets are widely adopted across enterprises, yet most implementations fail to influence real decision-making. Organizations invest in dashboards, SLO tracking, and observability tools, but the intended impact of error budgets is rarely realized.
Google invented the error budget. They described it in their Site Reliability Engineering book in 2016.
The idea is simple. Set a reliability target — say, 99.9% uptime. The error budget is what’s left: the 0.1% of time your service is allowed to fail. Over 30 days, that’s roughly 43 minutes of acceptable downtime.
When the budget is healthy, teams ship fast and take risks. When it runs out, they stop releasing and fix reliability instead. Clean logic. Powerful intent.
What the Industry Did With It
The industry took this elegant idea and turned it into a dashboard.
Most organisations now talk about error budgets in terms of monitoring tools, SLO platforms, and burn rate charts. The standard playbook: define your SLOs, connect them to your observability stack, watch the burn rate, and slow down releases when the budget drops too low.
That’s the conversation everyone is having. It’s missing the most important half.
The Numbers Behind the Gap
Three data points show what this omission costs.
ITIC’s 2024 Hourly Cost of Downtime Survey found that 93% of enterprises say downtime costs them more than $300,000 per hour. For 41% of large enterprises, it exceeds $1 million per hour.
The Catchpoint SRE Report 2026, based on 301 practitioners worldwide, found that 67% of SREs regularly feel pressured to prioritise release speed over reliability.
These aren’t abstract statistics. They reflect what happens when error budgets exist as metrics but are never used to make decisions.
That gap — between a metric and a decision-making tool — is what this article is about.
Error Budgets Are a Governance Tool
Google’s own SRE Workbook is direct on this. For error budgets to work, the organisation must commit to using them for decisions. That commitment must be written down as a formal error budget policy. Without it, the Workbook says, your SLO becomes just another KPI.
Read that again. The people who invented error budgets drew a clear line between a reporting metric and a decision-making tool. They said the missing piece is a policy — a formal, enforceable document.
Most enterprises have built the instrument panel. They haven’t written the constitution.
An error budget policy states — in advance and in writing — what happens at each depletion threshold. It defines consequences: a code freeze, a feature hold, mandatory reliability work, or rollback of recent changes. It names who has the authority to trigger those consequences. It lists the stakeholders from engineering, product, and business who are bound by the outcome.
It’s a governance document dressed up as a technical practice.
Why This Half Gets Skipped
The industry’s focus on dashboards over governance isn’t an accident. It reflects an uncomfortable truth: the technical side of error budgets is relatively easy. The governance side is hard — because it forces organisations to resolve tensions that are political and organisational, not technical.
Think about what a real error budget policy demands. Product management must accept that a feature freeze can happen automatically when a threshold is crossed — not as a conversation, but as a pre-agreed consequence. Engineering leadership must let an objective metric override their judgment when release pressure is high. The SRE team, or a monitoring system, must have standing to declare the budget exhausted.
These aren’t technical decisions. They’re decisions about power and accountability.
The Catchpoint SRE Report 2026 shows the cost of not resolving them. Time spent on repetitive operational work rose to 30% of engineering time in 2024, up from 25% the year before. More than two-thirds of practitioners feel regular pressure to ship over reliability. That pressure isn’t an attitude problem. It’s what happens when an organisation hasn’t formally decided who controls the trade-off between speed and stability.
An error budget without a policy is a speedometer with no speed limit. It shows you how fast you’re going. It doesn’t tell you who can hit the brakes, when they’re allowed to, or what happens if they don’t.
The DORA 2024 Accelerate State of DevOps Report, drawing on over 39,000 respondents, reinforces this. High-performing organisations achieve both speed and stability. They don’t trade one for the other. The mechanism isn’t better tooling. It’s clear decision rights, shared accountability, and policies that resolve the features-versus-reliability tension before a crisis forces the issue.
Observation can’t change behaviour. Only governance can.
Why This Gets Worse at Enterprise Scale
In a large organisation, skipping the governance layer doesn’t produce a slow, manageable decline. It produces cascading failure, driven by three compounding factors.
Service portfolio complexity. The Home Depot case study in Google’s SRE Workbook shows how fast this scales. They started tracking SLOs for around 50 services. Within a year, that number reached 800, with 50 new services added monthly. In a Fortune 500 environment, an error budget framework must cover hundreds or thousands of services, microservices, APIs, and data pipelines — each operated by a team with its own incentives. Without an enforceable policy across that portfolio, teams optimise for their own delivery speed. Reliability becomes a cost, not a shared resource. One team’s exhausted budget can cascade into another team’s incident.
Organisational fragmentation. The Catchpoint SRE Report 2026 found that 51% of reliability practitioners say observability in their organisation is insufficient. The 2026 Internet Resilience Report from Catchpoint found that 72% of respondents name the CIO or CTO as ultimately responsible for resilience — yet only 44% directly assign that responsibility to IT operations or SRE. That accountability gap is exactly what error budget policies are designed to close. At enterprise scale, the gap only widens.
AI workload complexity. DORA 2024 documents widespread AI adoption in software development with positive individual productivity effects. It also surfaces a counterintuitive finding: AI adoption doesn’t automatically improve stability at the team or system level. The Catchpoint SRE Report 2026 found that 57% of AI-related incidents are caught immediately, but 43% of organisations still rely on reactive detection. AI introduces a new class of reliability risk that existing error budget frameworks — built for deterministic services — aren’t yet equipped to handle.
ITIC 2024 confirms the stakes: 97% of enterprises with more than 1,000 employees say a single hour of downtime costs more than $100,000. In banking, healthcare, retail, and manufacturing, average hourly costs exceed $5 million. These are the numbers that error budget policies exist to prevent from repeating.
This Is an Operating Model Problem
The core argument here is this: implementing error budgets at enterprise scale is not a metrics problem. It’s an operating model problem. Until leaders frame it that way, implementation will keep stalling at the observability layer.
Google’s SRE Workbook is explicit about what’s needed before error budgets can work. All stakeholders must agree that the SLOs are right for the product. The teams responsible for meeting them must believe the targets are achievable. The organisation must formally commit to using the budget for decisions. And there must be a process to refine the SLO over time. Every one of these conditions requires cross-functional alignment and defined decision rights. An engineering team working in isolation cannot create them.
Google’s SRE book makes the structural conflict clear. Product teams are measured on velocity — so they push to ship fast. SRE teams are measured on reliability — so they push back against frequent changes. The error budget is supposed to replace that negotiation with objective data. But it only works if both sides are bound by a shared policy they agreed to before the dispute arose.
In most enterprises today, that pre-commitment doesn’t exist. SRE teams define SLOs and instrument the budgets. Product teams acknowledge them. But when the budget runs out and the policy should trigger a code freeze or a reliability sprint, the conversation reverts to negotiation. The metric is visible. The governance is absent. And reliability suffers for it.
Fixing this requires action at the operating model level. The CIO or CTO must establish error budget policy as a governance artefact — with the same organisational weight as a security policy or a financial control. Product leadership must co-own SLO definitions, not passively receive metrics from engineering. And the consequence framework in the policy must be enforced, not just documented.
What Correct Implementation Actually Requires
Three operating model conditions separate error budget adoption from error budget governance.
First: the policy must be a cross-functional document, not an engineering deliverable. Google’s SRE Workbook includes a policy template that covers depletion thresholds, consequences such as feature freezes and mandatory postmortems, escalation paths, and the stakeholders bound by each clause. This document cannot be authored by the SRE team alone. It must be co-authored by product management, engineering leadership, and business leadership — and binding on all of them. In a Fortune 500 enterprise, that process requires VP or C-suite engagement. It is not a sprint task.
Second: SLO ownership must sit with product or business, not engineering. Google’s SRE Workbook is clear: once an organisation accepts that 100% availability is the wrong goal, the SLO that replaces it must be owned by someone with authority to make trade-offs between features and reliability. In most organisations, that’s the product owner or product manager. SLO ownership is a business accountability, not a technical one. When it defaults to the SRE team, the team ends up enforcing consequences against product leadership without the standing to do so. The policy collapses.
Third: SLOs must reflect actual business risk tolerance, not aspirational targets. Google’s SRE book contrasts Google Apps for Work — an enterprise product requiring high reliability — with YouTube at acquisition, then a consumer product in fast growth where lower reliability was commercially acceptable. The right SLO is not the highest achievable SLO. It’s the one that accurately reflects user expectations and business risk. Enterprises that set aspirational targets without grounding them in user data and business impact analysis will burn through budgets fast, trigger consequences that can’t be sustained, and erode the entire framework.
The Question Every CIO and CTO Should Be Asking
SRE as a discipline is now over two decades old. Error budgets have been publicly documented since 2016. The DORA research programme has been running for more than ten years. The intellectual foundation for doing this right is not missing. What’s been missing is the will to implement the governance layer — which requires C-suite engagement, cross-functional commitment, and the acceptance of enforceable consequences.
The Catchpoint SRE Report 2026 captures where most enterprise reliability programmes actually stand: the features-versus-reliability battle is ongoing, and it will remain so in any organisation without a reliability culture strong enough to hold under pressure. That culture isn’t built through awareness campaigns. It’s built through governance instruments that enforce trade-offs at the exact moment they’re hardest to make: when the release schedule is under pressure and the budget is gone.
The question every CIO and CTO in a large enterprise should be asking is not whether they have error budgets. Most organisations with SRE capability have some form of SLO monitoring in place.
The real question is: when the error budget is exhausted, who has the authority to freeze a release — and have product and business leadership agreed to that authority in writing, before the crisis arrives?
If the answer requires a conversation at the time of exhaustion, the error budget is a reporting metric. And the $300,000-per-hour cost of that distinction will keep accruing.
The technical layer of error budgets is the easier problem. The governance layer is the hard one. The industry has spent a decade solving the easy problem. It’s time for enterprise technology leaders to focus on the hard one — not because it’s technically interesting, but because it’s the one with a seven-figure hourly price tag.
