Error Budget Policy: [Service or product name]

Policy that turns service level objectives (SLOs) into decisions: how the error budget is calculated, what happens when it is being spent too fast or is exhausted, who decides, which exceptions apply and how the policy is reviewed. Based on the error budget concept from site reliability engineering practice. Replace every [bracketed] value and every row marked Example.

1. Purpose and principles

This policy balances the speed of change against the reliability users expect. The SLO defines how unreliable the service is allowed to be; the difference between perfect and the SLO is the error budget. While budget remains, teams may spend it on releases, experiments and planned risk. When it is spent, reliability work takes priority until the service is back within objective.

Principles:

• 100% is the wrong target. Users cannot tell the difference above the SLO, and chasing it slows delivery.
• The budget belongs to the product, not to one team. Spending and saving it are joint decisions.
• Consequences are triggered by data, not by opinion or by the loudest voice in the room.
• The policy applies to all changes, including those from platform and dependency owners, unless an exception in section 6 applies.

2. SLOs covered

3. Budget calculation

For an SLO target $T$ over a window, the error budget is the allowed share of bad events:

For request-based SLIs, the remaining budget at any time is:

Example: SLO-01 has $T = 99.9\%$ and 28 days of traffic with $50{,}000{,}000$ requests. The budget is $0.001 \times 50{,}000{,}000 = 50{,}000$ bad requests. With $18{,}500$ bad requests so far, the remaining budget is $1 - 18{,}500 / 50{,}000 = 63\%$.

For time-based reasoning, a 99.9% availability target over 28 days allows $0.001 \times 28 \times 24 \times 60 \approx 40$ minutes of full downtime.

The burn rate shows how fast the budget is being spent relative to the rate that would use exactly all of it by the end of the window:

A burn rate of 1 spends the budget exactly over the window; a burn rate of 14.4 sustained for one hour spends 2% of a 30-day budget.

Live values are shown on [dashboard link] and reported weekly in [channel or meeting].

4. Policy thresholds and consequences

4.1 Single-incident rule

Any single incident that consumes more than [20%] of the window's budget requires a postmortem with at least one priority action to prevent recurrence, whatever the overall level.

4.2 Reliability work

Reliability work under Orange or Red is chosen from the reliability backlog ranked by budget impact. Example: fix the retry storm found in INC-2310, add load shedding to the search API, raise test coverage on the checkout flow from 61% to 80%.

5. Escalation

6. Exceptions

The following do not count against the budget, or allow releases during a freeze, when approved by [role] and recorded in the exceptions log:

• Outages caused by a dependency with its own SLO that is covered by its own policy, when this service degraded gracefully as designed.
• Planned maintenance announced at least [5 working days] in advance and within the agreed maintenance window.
• Security fixes and legal or regulatory changes, which may always ship.
• Load from abuse or attack that is blocked within [15 minutes] of detection.
• Fixes that reduce budget burn, which are always allowed.

7. Reporting and review

Signs that the SLO or policy needs revision: the budget is never used (target may be too loose or the team too cautious), the budget is exhausted every window (target too tight or the system needs investment), or users complain while the SLO is met (the SLI measures the wrong thing).

8. Sign-off

By signing, the parties agree to apply this policy as written until it is revised.

Standard and licence note

Based on common site reliability engineering practice for service level objectives, error budgets and burn-rate alerting. This template describes the concepts in original text and reproduces no published policy. Template licence: MIT.