Error Budget Policy

Definition

An error budget policy is the written, signed-off agreement between engineering, product management and business stakeholders that defines what actions are triggered when a service consumes its error budget. The error budget is the allowable amount of unreliability implied by an SLO — if the SLO is 99.9% over a 30-day window, the error budget is 43 minutes and 12 seconds of downtime, or 0.1% of requests failing. The policy answers the question: when we burn that budget faster than expected, what do we actually do about it?

Why It Matters

SLOs without policies are wallpaper. Every SRE team can produce dashboards showing reliability targets; only teams with genuine error budget policies use those targets to make product decisions. The policy is what converts a reliability metric into an organisational commitment. Without it, teams either treat every incident as a crisis (unsustainable) or ignore reliability until customers complain (uninsurable). With it, the answer to "should we ship this feature or improve reliability?" is decided in advance, not in the meeting.

Anatomy of a Good Policy

• The SLO it applies to — specific service, specific SLI, specific window.
• The error budget calculation — how "budget remaining" is computed.
• Burn-rate thresholds — typically 2x, 5x and 10x normal burn, with escalating responses.
• Actions at each threshold — the concrete, non-negotiable behaviours.
• Escape valves — how to override the policy for genuine emergencies, and who signs.
• Review cadence — quarterly at minimum, more often if the service is new.

Example Policy Ladder

• Budget healthy (>50% remaining): normal product cadence; risky changes permitted.
• Budget tight (25–50% remaining): risky changes require SRE sign-off; reliability items prioritised in next planning cycle.
• Budget critical (<25% remaining): feature freeze on the service; only reliability work merged.
• Budget exhausted (0%): full feature freeze, incident review of the burn, escalation to engineering leadership.
• Fast burn (10x rate, any budget): page the on-call, freeze deploys immediately regardless of remaining budget.

Real-World Example

A B2B SaaS provider had a 99.95% availability SLO for its checkout API. The error budget policy said "feature freeze at 25% budget remaining." Six months into using the policy, a major release consumed 40% of the monthly budget in three days through a slow database query. Under the policy, the team froze the feature branch, reallocated four engineers to reliability work for the remainder of the month, and shipped a query optimisation and a caching layer. The next quarter, the service ran at 99.97% and the budget was fully recovered. Product initially objected — a marketing campaign was tied to a feature release. The CTO cited the signed policy and the product team accepted the delay. Two things were preserved: the customer experience and the credibility of the SLO. Without the policy, both would have been sacrificed to the campaign date.

How to Introduce It

1. Agree the SLOs first. A policy without a well-chosen SLO is meaningless.
2. Draft the policy jointly — engineering, product, business owner in the same room.
3. Start with a soft version — advisory triggers rather than hard freezes, for one quarter.
4. Publish it — internal wiki, referenced from the runbook, cited in every incident review.
5. Wire it to alerting — burn-rate alerts should fire before humans need to check dashboards.
6. Enforce the first time it triggers. Every subsequent enforcement is easier; every skipped enforcement erodes the policy.
7. Review quarterly, adjusting thresholds and actions based on operational reality.

Practical Lessons Learned

• The first enforcement is the whole game. If leadership overrides it, the policy is finished.
• Burn-rate alerts beat static thresholds. A 10x burn on day one is more urgent than 50% consumed on day 25.
• Product resistance is normal. The policy is the mechanism to negotiate the disagreement in advance.
• Reliability work should be pre-refined. When a freeze kicks in, the backlog of reliability items should be ready to grab; scrambling for scope wastes the frozen time.
• Regional and per-tenant budgets scale better than a single global budget as the service grows.

Expert Tips

• Include the policy text in the runbook so on-call engineers can cite it during incidents without needing to negotiate.
• Show the budget remaining on the team's main dashboard — visibility drives behaviour more than any policy clause.
• Distinguish planned from unplanned burn. Planned downtime for a database migration should draw against a separate maintenance budget, not the customer-facing SLO budget.
• Include an explicit clause that says the policy applies to executives too. The exceptions kill it faster than the rules.
• Track policy triggers as a metric. Zero triggers in a year means the SLO is too generous; monthly triggers mean the SLO or the operational discipline needs work.

Common Mistakes

• Policy written but never signed by the product side; when it triggers, it is disputed.
• Policy actions vague ("engineering will focus on reliability") rather than concrete ("no new feature merges to main").
• No fast-burn clause; the team notices only when the monthly budget is exhausted.
• First trigger overridden for "business reasons," setting the precedent that the policy is negotiable.
• Static thresholds on burn rate instead of multi-window alerts, producing both false positives and missed real burns.

Key Takeaways

• An SLO without a policy is a poster.
• Draft, sign and publish before the policy is needed — never during an incident.
• Concrete actions beat abstract intent.
• Burn-rate alerting is more useful than budget-remaining alerting.
• The first enforcement determines whether the policy survives.

Related Concepts

Pairs with Service Level Objective, Service Level Indicator, Deployment Freeze Window, and Post-Incident Review.