Since lesson 3.15.1, the Kladde has objectives: 99.5% of the requests to the booking page without a server error, measured over 30 days. An objective below 100% also says something else: 0.5% may go wrong. This allowed unreliability is called the error budget. That sounds like an excuse, but it is a tool. The budget answers a question that teams otherwise argue about: May we roll out a new feature today, or do we take care of reliability first?
In this lesson you calculate the budget, measure how fast an incident burns through it, and build two alerts on top that fire early for a real
problem and not at all for a harmless one. At the end, the pipeline checks before every rollout to prod whether any budget is left.
The budget: allowed unreliability
The budget is one minus the objective. At 99.5%, that is 0.5%. How much that is depends on how you count:
- In events. If the booking page gets 40,000 valid requests in 30 days, 200 of them may end with a server error. Every bad request subtracts one from the budget, no matter when it came.
- In time. If the page goes down completely, all requests are bad. Then the budget covers 0.5% of the time: 0.005 × 30 × 24 × 60 = 216 minutes in 30 days.
| SLO over 30 days | Budget | Total outage that uses up the budget |
|---|---|---|
| 99% | 1% | 432 minutes, a little over seven hours |
| 99.5% | 0.5% | 216 minutes, a little over three and a half hours |
| 99.9% | 0.1% | 43.2 minutes |
| 99.95% | 0.05% | 21.6 minutes |
The Kladde counts in events, because its SLI is a share of requests (3.15.1). The minutes are the illustrative side of the same number: They say how long a complete outage may last. An incident in which only one request in ten fails uses up the budget ten times more slowly.
The budget makes two things visible that a single number like "99.3% yesterday" hides:
- How much room is left. If half of it is gone after ten days, that is a reason for caution, even if everything is running right now.
- That reliability costs something. Every delivery carries a risk. A budget that is never touched usually means that the objective is too low or that the team delivers too cautiously. Either one is information.