Error budget
The failure you are allowed before you break your SLO: 99.9% means 0.1% of requests can fail, and that 0.1% is a budget you spend.
See it
What it is
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, which over 30 days is about 43 minutes of total badness. 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.
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).
Ask AI for it
Build an error budget view for a service with a 99.9% availability SLO over a rolling 28-day window. Compute total budget as 0.1% of valid requests, budget consumed as the count of bad events so far, and budget remaining as a percentage plus an equivalent in minutes of full outage. Add multi-window burn-rate alerts in the Google SRE style: page at 14.4x burn over 1 hour and 6x over 6 hours, ticket at 1x over 3 days. Render it as a dashboard panel with remaining budget, current burn rate, and the projected exhaustion date.