Express error budgets as numbers with time windows — '2…
Express error budgets as time-bounded numeric thresholds (e.g., 'two missed sessions per week' or '30 minutes downtime per month') rather than vague intentions, and track consumption against the budget as a first-class metric.
When This Fires
- When defining error budgets for any system (Define your error budget in writing) — express them in this format
- When existing standards are vague ("be good about...") and need conversion to trackable budgets
- When reviewing budget design for actionability — vague budgets don't trigger investigation
- When tracking budget consumption as part of regular system monitoring
Common Failure Mode
Budgets without time windows: "I allow myself to miss 5 sessions." Over what period? Five misses in a week is catastrophic; five misses in a year is exemplary. Without the time window, the budget is ambiguous and the exhaustion threshold is undefined. Always pair the number with the period.
The Protocol
(1) For each error budget, express as: "[Number] [unit of deviation] per [time period]." Examples: "2 missed writing sessions per week." "3 late deliveries per quarter." "1 skipped review per month." (2) Track consumption actively: at any point in the period, you should know how many of your allowed deviations you've used. (3) When approaching budget limit (e.g., 1 deviation remaining with 3 days left in the period), increase attention — your margin is gone. (4) At period end: was the budget respected? If yes → the system is performing within tolerance. If no → investigate the pattern (When error budget is exhausted, analyze the pattern…). (5) Review the budget itself quarterly: is it appropriately calibrated? Too generous (you never approach the limit) → tighten. Too strict (you exhaust it constantly) → either the system needs structural improvement or the budget needs loosening.