A team has a 99.9% availability SLO, giving about 43 minutes of error budget a month. Three weeks in, the budget is untouched. What does that actually permit the team to do, and what does an untouched budget indicate?

The mechanism

An error budget converts a reliability target into a quantity of permitted unreliability. 99.9% over a 30-day month is roughly 43 minutes during which the service may be failing without breaking its promise.

The move that makes this useful is treating the budget as a resource to spend rather than a limit to avoid. Those 43 minutes are what buys deploying on a Friday, migrating a database under live traffic, running a chaos experiment, or shipping a risky feature behind a flag. A team with budget remaining is authorised to take risk; a team that has exhausted it is not. That is the whole mechanism, and it replaces a negotiation about how careful to be with a number both sides already agreed.

What an untouched budget indicates

Not success. An error budget consistently unused is evidence that the team is being too conservative, that the SLO is set lower than the service's actual reliability, or both.

Either diagnosis has an action. If the service genuinely runs at 99.99%, the SLO is wrong and should be raised — a target nobody can fail provides no information and authorises nothing. If the service could run at 99.9% but the team is shipping at a quarter of its possible pace to stay safe, the unspent budget is being paid for in delivery speed, and that is a cost the organisation did not choose and cannot see.

This is the counterintuitive half of the idea and the reason it is not just a renamed SLA: the target is two-sided. Both over-spending and under-spending are findings.

What the budget permits here

With three weeks gone and 43 minutes intact, the team can reasonably: ship the deferred risky migration now rather than next quarter; raise deploy frequency; run the game day they have been postponing; turn off a belt-and-braces mitigation nobody has justified. The budget is strongest at the start of a window and should be spent deliberately rather than conserved by default, because it does not roll over.

What it does not permit

• Spending it all at once on purpose. 43 minutes of continuous downtime is one incident, and SLO compliance is not the only thing that matters — a single 43-minute outage damages trust more than forty one-minute blips, although the arithmetic is identical. Burn-rate alerting exists to catch the fast consumption separately.
• Ignoring the budget's composition. 43 minutes affecting all users differs from 43 minutes affecting one tenant. If the SLO is a global ratio, a severe single-customer outage may barely register, which is why important customers need their own SLO rather than a share of the aggregate.
• Overriding a severity call. A security incident or data loss is not a budget question.

When error budgets are the wrong tool

They require enough traffic for the ratio to mean something. At a few hundred requests a day, one failed request is a large fraction of the budget, and the measurement is noise rather than signal. Below that volume, count incidents and their durations directly.

They also need an agreed consequence, and this is where the practice usually fails. If exhausting the budget does not actually stop feature work in favour of reliability work, the budget is a report rather than a control, and nobody will change behaviour because of it. An error budget with no enforced consequence is a metric, not a mechanism — and a team that has one should say so plainly rather than maintaining the ceremony.

Common weak answers

• "It means we are doing well." It means the target is uninformative or the pace is too cautious. Both are problems.
• "We should keep it in reserve." It does not roll over, and unspent budget is unspent delivery.
• "43 minutes is our maximum allowed outage." It is a monthly total across all incidents, and spending it in one go is worse than spending it in forty pieces for the same arithmetic.
• Reciting the number without the consequence. The budget is only a mechanism if exhausting it changes what the team is allowed to do.