Error budget

An error budget is the leftover of an SLO. Target 99.9% and you have explicitly said 0.1% of requests are allowed to fail, so the budget is a count of bad events: one failed request for every thousand valid ones across the window. The familiar 'about 43 minutes per 30 days' is that same 0.1% measured against a time-based availability SLI, and it lines up with the request budget only when traffic is perfectly flat, which it never is. Express a request SLO's budget in bad events and save the minutes for an SLI that is genuinely about time. That 0.1% is not a failure, it is an allowance you get to spend on risky deploys, migrations, and experiments. Spend it wisely and you ship fast. Spend it in one bad Tuesday and the rest of the month is repair work.

The point is the policy attached to it. While budget remains, feature work continues and risk is fine. When it runs out, the team freezes risky changes and spends the cycle on reliability instead. That single rule replaces a lot of arguing between the people who want to ship and the people who want it stable, because both sides now read the same gauge. Burn rate is the companion number: 1x means you finish the budget exactly at the end of the window, 14.4x means you will torch a month's budget in two days, which is what a good page fires on. The Google SRE version of that page is a multi-window rule: a long window proves the burn is sustained and a short window proves it is still happening, and both have to be over the threshold at once, so a two-minute blip does not wake anyone.

Gotcha: an error budget with no teeth is just a chart. If the freeze never actually happens, the budget goes permanently negative and people stop looking. Decide up front whether the window is a rolling 28 days (budget recovers gradually, no free reset) or a calendar month (everyone waits for the first, which is exactly the wrong incentive).