Error Budget Policy

Overview

An error budget is the amount of unreliability an SLO permits. If the SLO is 99.9 percent success over 30 days, the budget is 0.1 percent of requests, or about 43 minutes of full downtime. The budget turns reliability into a currency teams can spend on releases, experiments, and migrations.

How it works

Budget consumption is computed from the SLI:

budget_total     = (1 - SLO) * events_in_window
budget_consumed  = bad_events_in_window
budget_remaining = 1 - budget_consumed / budget_total

Policy example
  remaining above 50 percent : ship normally
  remaining 0 to 50 percent  : require canary and rollback plan
  remaining at 0             : freeze features, fix reliability

The policy document is agreed in advance by product, engineering, and operations, and names an escalation path when parties disagree. Exceptions, such as security patches, are listed in the policy. A burn-rate alert warns before the budget is gone.

Pitfalls

• Writing a policy that nobody enforces. The budget becomes a decorative graph.
• Choosing an SLO from aspiration instead of user need. A 99.99 percent target for a tolerant internal tool wastes effort.
• Counting outages caused by third parties against the team without discussing whether the SLO accounts for them.
• Using a window so long that old incidents mask current problems, or so short that one blip exhausts it.

Key takeaways

• The budget is one minus the SLO, measured over a fixed window.
• A pre-agreed policy removes argument during crunch time.
• Spend the budget deliberately; unused budget suggests too much caution.
• Pair it with burn-rate alerts for early warning.