11.5Error Budgets: The Key Insight

The error budget is the most powerful concept in SRE. It turns reliability into a measurable resource that can be spent:

SLO Target	Error Budget (30 days)	Equivalent Downtime
99%	1.0%	~7.3 hours
99.5%	0.5%	~3.6 hours
99.9%	0.1%	~43.8 minutes
99.95%	0.05%	~21.9 minutes
99.99%	0.01%	~4.4 minutes

Error Budget Policy

The error budget policy defines what happens as the budget is consumed:

# error-budget-policy.yaml
service: checkout-api
slos:
  - name: availability
    sli: successful_requests / total_requests
    target: 99.95%
    window: 30d
    error_budget: 0.05%

  - name: latency
    sli: requests_under_500ms / total_requests
    target: 99.0%
    window: 30d
    error_budget: 1.0%

policy:
  budget_remaining_above_50pct:
    - Deploy normally
    - Run chaos experiments
    - Ship new features
    - Experiment with new architectures

  budget_remaining_25_to_50pct:
    - Reduce deployment frequency
    - Pause non-critical chaos experiments
    - Prioritize reliability work in sprint planning
    - Review recent deployments for regressions

  budget_remaining_below_25pct:
    - Feature freeze for this service
    - All engineering effort on reliability
    - Incident review for every budget-consuming event
    - Escalate to engineering leadership

  budget_exhausted:
    - Full deployment freeze except hotfixes
    - Executive escalation
    - Postmortem required for next deployment
    - Consider rollback of recent changes

Why Error Budgets Change the Conversation

Without error budgets, the reliability discussion is adversarial:

• Product team: "We need to ship this feature."
• QA/SRE team: "It is not ready. More testing needed."
• Result: Endless negotiation, no objective criteria.

With error budgets, the discussion is data-driven:

• Product team: "We need to ship this feature."
• QA/SRE team: "We have 60% of our error budget remaining. We can ship, but we need to monitor closely."
• Result: Objective decision based on measurable risk.