Reliability targets Updated
Error budget policy
An error budget policy is a short document, agreed in advance by engineering and product, that says what the team does when it spends too much of its error budget. It is what makes an SLO change behaviour instead of just decorating a dashboard. Jump to the policy template.
On this page
Why write one
The error budget (1 − SLO) is the amount of unreliability the service may have in a window. While budget remains, the team can take risks: ship faster, run experiments, do risky migrations. When the budget is gone, reliability work takes priority. Deciding this in the middle of an outage leads to arguments; deciding it beforehand, with named owners, turns a judgment call into a rule both sides already accepted.
What a good policy contains
- Scope: which services and SLOs it covers, and the window it uses.
- Thresholds and consequences: what happens at defined levels of budget spend, including exhaustion.
- Exceptions: what is still allowed during a freeze (security fixes, fixes for the SLO miss itself).
- Incident triggers: when a single incident or class of incidents demands a postmortem and priority work.
- Exclusions: how to treat budget spent by dependencies, load tests, or a miscalibrated SLO.
- Escalation: who decides when the team disagrees about applying the policy.
- Review date and approvers: the policy is a living agreement.
Error budget policy template
Adapted from the example policy in Google’s SRE Workbook. Replace the bracketed parts; tune the numbers to your service.
Error budget policy: [service name]
Owners: [engineering lead], [product lead] Approved: [date] Review: [date + 1 year]
Service overview
[One paragraph: what the service does and who depends on it.]
SLOs covered
- Availability: [99.9]% of valid requests succeed over a rolling [28] days
- Latency: [99]% of valid requests complete in under [300 ms] over a rolling [28] days
Goals
- Protect users from repeated SLO misses.
- Give the team an incentive to balance reliability with feature work.
Non-goals
- This policy is not a punishment for missing SLOs.
- Halting change is not desirable; it is the cost of unreliability.
Policy
While the service is within its SLOs, releases proceed under the normal process.
If the service has exceeded its error budget for the preceding window, the team
halts all changes and releases other than [P0 issues / security fixes] until the
service is back within its SLO. Work to restore reliability takes priority over
feature work until then.
Depending on the cause, the team may also:
- work only on reliability issues until back within SLO,
- protect the system from known failure causes (rate limits, rollbacks),
- slow release cadence or require extra review for risky changes.
Outage policy
- If a single incident consumes more than [20]% of the error budget over the
window, the team conducts a postmortem containing at least one highest-
priority action item addressing the root cause.
- If a single class of outage consumes more than [20]% of the error budget over
a quarter, the team schedules work to fix it in the next planning cycle.
Exclusions
- Budget consumed by a dependency outage still counts, but the freeze may be
lifted early by agreement if the fix lies with the dependency's owners.
- Errors that were miscategorised and had no user impact (for example, a
monitoring bug counting good requests as bad) are removed by recomputing the
corrected SLI. Genuine failures are never excluded.
Escalation
Disagreements about the calculation or application of this policy are escalated
to [CTO / VP Engineering] for a decision.
Background
[Links to SLO definitions, dashboards, alert rules, and this policy's history.]Graduated responses
Many teams find a single cliff at 100% too blunt. A graduated policy reacts earlier and more gently. One common pattern (a starting point, not a standard):
| Budget remaining | Response |
|---|---|
| More than 50% | Normal release cadence; experiments allowed. |
| 25–50% | Review the biggest consumers of budget; prefer low-risk changes. |
| 0–25% | Extra review for risky changes; reliability items move up the backlog. |
| Exhausted | Freeze per policy until back within SLO. |
Making it work
- Get sign-off from product. A policy that engineering wrote alone will be overridden the first time it bites.
- Make spend visible. Put budget remaining on the team’s main dashboard and in planning meetings.
- Alert on fast burn. Use burn-rate alerts so budget-threatening problems page someone before the budget is gone.
- Handle the never-spent budget. A service that never uses its budget may have an SLO that is looser than it needs or more reliability work than users need. Check user feedback first: tighten the target only if users need more, otherwise take more risk, for example by releasing faster or relaxing reliability work.
- Review after each freeze. If a freeze did not help, the SLO, SLI or policy probably needs changing.
Source: Google, The Site Reliability Workbook, “Example Error Budget Policy”.