Error Budget Calculator

How much failure you have left

With an SLO of 99.9% over 3,000,000 requests, the error budget is 3,000 failed requests. Against 1,500 actual failures, half the budget remains — which, at the midpoint of a period, is precisely on pace.

An error budget is the quantity of failure a service is permitted before it breaches its objective. It is the inverse of the SLO, and its purpose is to turn reliability from an argument into an accounting exercise.

The calculation

Error budget (%) = 100 − SLO Allowed failures = total events × error budget ÷ 100 Budget consumed (%) = actual failures ÷ allowed failures × 100 Budget remaining = allowed failures − actual failures

Here: 100 − 99.9 = 0.1%. 3,000,000 × 0.001 = 3,000 allowed. With 1,500 actual, consumption is 50% and 1,500 failures remain available.

Note how much larger the budget becomes with volume. The same 99.9% SLO gives 3,000 allowed failures at three million requests and 30 at thirty thousand — which is why low-traffic services often need a longer measurement window to produce a statistically meaningful SLI at all.

What to do with the number

The operating discipline is straightforward, and its value comes from agreeing it before you need it:

Budget healthy (well under pace) — ship. Deploy the risky change, run the chaos experiment, take the migration. Unspent budget is not a prize; it is evidence you could have moved faster.

Budget on pace — normal operations, keep watching.

Budget nearly exhausted — slow down. Increase review rigour, defer non-essential changes, prioritise the reliability work that has been queued.

Budget exhausted — the agreed policy takes effect. Typically that means a feature freeze until the next window, with engineering time redirected to the causes of the burn.

The policy matters more than the threshold. A team that has agreed in advance what exhaustion means avoids relitigating priorities during an incident, which is the worst possible time to have that conversation.

Not all burn is equal

A budget consumed by one large outage and a budget consumed by a steady trickle of errors are numerically identical and operationally very different. The outage is a discrete event with a root cause and a fix. The trickle usually indicates systemic degradation — a dependency slowly failing, a resource leak, a retry storm — and is often the more serious signal despite feeling less dramatic.

It is worth tracking both the total consumed and the shape of consumption over the window.

Windows

Most teams use a rolling 30-day window rather than a calendar month. A rolling window avoids the artefact where reliability resets at midnight on the first, and prevents a bad final week from being forgiven simply because the calendar turned.

Longer windows are more forgiving of single incidents and slower to react; shorter windows are noisier. Thirty days is the common compromise.

Common mistakes

Treating unspent budget as success. Consistently finishing a window with 90% of the budget unused suggests the SLO is set too loosely to be useful, or that the team is being more cautious than the target requires.

Counting planned maintenance against the budget. Decide explicitly whether it counts; most teams exclude announced maintenance, which is also how SLAs usually treat it.

Using one budget for everything. Critical and non-critical paths deserve separate objectives.

Measuring failures inconsistently with the SLO definition. If the SLO counts slow responses as failures, the budget must too.