Error Budget
An error budget is the allowed amount of bad service during an SLO window. It equals the part below 100%.
allowed bad events = (1 - SLO) × valid events; consumed share = bad events / allowed bad events1,000○allowed700−used300✓remainingallowed bad events = (1 - SLO) × valid events; consumed share = bad events / allowed bad eventsSREAnother example
A service has a 99.9% SLO for one million requests. The budget allows 1,000 bad requests. After 700, 300 remain.
Main parts
- 01Linked SLO
- 02Budget window
- 03Allowed bad events
- 04Consumed amount
- 05Remaining amount
- 06Release decision policy
Use it when
Use it after a team agrees on an SLO and a policy. Let remaining budget guide release and reliability work.
Do not use it when
Do not treat the budget as planned downtime or a punishment. It is a shared signal for making tradeoffs.
Name used in code
allowed bad events = (1 - SLO) × valid events; consumed share = bad events / allowed bad events Before you ship
Check contracts and invariants, authorization, and input limits. Test retries, one-time effects, timeouts, and partial failures. Verify data integrity, compatibility, monitoring, recovery, and rollback.
Outcome: Design or review Error Budget for this system while keeping data correct, secure, and easy to operate. User context: A service has a 99.9% SLO for one million requests. The budget allows 1,000 bad requests. After 700, 300 remain. Technical concept or control: Error Budget. Why it fits: Use it after a team agrees on an SLO and a policy. Let remaining budget guide release and reliability work. Do not use it when: Do not treat the budget as planned downtime or a punishment. It is a shared signal for making tradeoffs. Engineering requirements: Define inputs, outputs, contracts, and rules that must always hold. Set authorization and input checks. Define failures, timeouts, retries, one-time effects, data moves, and compatibility limits. Operations: Add useful signals and logs that hide sensitive data. Set capacity limits and write an operator guide. Test recovery and rollback. Acceptance criteria: Contract and failure-path tests pass. Data and authorization rules still hold during retries and partial failures. Check performance limits, monitoring, recovery, and rollback. Evidence and limits (evidence boundary): No single official standard controls the whole term. Its meaning may change across teams, platforms, or frameworks. Unknowns to confirm: Where the code runs, data stores, traffic shape, consistency needs, and the security boundary. Also confirm the compatibility period, service goals, and rollback limits.
Check this request
Review the current use of Error Budget. Definition: An error budget is the allowed amount of bad service during an SLO window. It equals the part below 100%. Release checks: Check contracts and invariants, authorization, and input limits. Test retries, one-time effects, timeouts, and partial failures. Verify data integrity, compatibility, monitoring, recovery, and rollback. Before changing code, report the evidence you found, gaps, severity, and the smallest safe fix.