1. Calculating the budget #
What you are allowed to miss.
Formula #
The error budget is the share of events allowed to fail: 1 - SLO. With a 99.9% SLO over 30 days and 10 million requests, the budget is 10,000 failed requests.
| Quantity | Calculation | Example |
|---|---|---|
| Total budget | (1 - SLO) × requests | 0.001 × 10,000,000 = 10,000 |
| Budget consumed | observed errors / total budget | 4,000 / 10,000 = 40% |
| Budget remaining | 1 - consumed | 60% |
| Burn rate | observed error rate / (1 - SLO) | 0.3% / 0.1% = 3 |
Good to know: A burn rate of 1 consumes exactly the budget over the SLO window. A burn rate of 3 exhausts it in 10 days instead of 30.
2. The error budget policy #
A written agreement between product and operations.
Example policy #
The budget is only valuable if it triggers decisions, decided in advance and signed off by the product and engineering teams:
| Budget remaining | Decision |
|---|---|
| > 50% | Normal releases, experiments allowed |
| 20 to 50% | Normal releases, review of the month's incidents |
| 0 to 20% | Priority to reliability work, risky deployments postponed |
| Exhausted | Feature freeze: only fixes and reliability work are shipped until back within the objective |
Good practice: The budget works both ways: a budget that is never consumed means the objective is too cautious or that the team could ship faster.
3. Rolling or calendar windows #
Over what period to measure?
Choosing #
| Window | Advantage | Drawback |
|---|---|---|
| Rolling (28 or 30 days) | Reflects recent experience, no « reset » effect | An incident weighs for 30 days |
| Calendar (month) | Aligned with SLAs and reports | The budget resets on the 1st, encouraging opportunistic behavior |
In practice: a rolling window of 28 or 30 days to steer, a calendar report for the SLA. 28 days contain exactly four weeks, which neutralizes the effect of weekends.
