Template
Agree what reliability loss will pause ordinary changes
Decide the response before the next outage supplies the emotion.
When it fits
- Every incident restarts the argument between shipping features and stabilizing the service.
When to avoid it
- Choose targets locally; an example policy's percentages and windows are not universal. Do not use the budget to punish individuals or hide severe incidents inside averages.
A template to use
User-facing reliability measure: [measure]. Objective and window: [target]. If the budget is exhausted: [response]. Exceptions and approval: [exceptions]. Conditions for resuming: [resume].
Why it matters
An error-budget policy connects an agreed reliability objective to release decisions. Define the measurement, observation window and response when the allowed shortfall is exceeded. Keep emergency and security exceptions explicit. The aim is a shared operating rule, not permission to neglect users until a number turns red.
An example
A service pauses ordinary feature releases after its agreed reliability limit is exceeded, while approved security fixes and recovery work continue.
Check your result
The same measured condition leads to the agreed response without inventing a new rule for each team.
Keep this limit in mind
- Choose targets locally; an example policy's percentages and windows are not universal. Do not use the budget to punish individuals or hide severe incidents inside averages.
Connected ideas
Useful withGive the canary a fair comparison and a real stopping rule
Evidence and sources
The example error-budget policy links reliability performance to release decisions, with defined exceptions, and explicitly frames the policy as nonpunitive.
A suitable target, measurement window and exception process depend on the service; the example is not a universal operating standard.
Example Error Budget Policy · Goals; Policy