LatentEval

INSTRUMENT | Reliability testing

AI SLO Error Budget Calculator: Split a Failure Budget Across Classes

2 cited sources

Turn a completion-rate target and a task volume into a failure budget split by class, with a Wilson interval on each class observed rate against its allowance.

An error budget is the failure count a completion-rate target buys, over a stated task volume and window. This calculator splits it across the classes you name, so no single percentage hides which one is spending it.

It builds on our research on agent reliability as several measured properties and our playbook for budgeting production failures by class.

Target and volume

The acceptable completion rate this budget is measured against.

Check this value.

Tasks expected in the window.

Check this value.

Window

The budget's rolling or calendar window.

Check this value.

For a pace reading. Leave blank to hide it.

Check this value.

Scoring

Needed before any observed rate or interval shows.

Check this value.

Check this value.

Failure classes
Class Share % Hard invariant Observed Remove

A hard-invariant class takes zero budget; any observed failure on it is a breach, and its points become available for you to reassign to the classes that can spend. This tool does not redistribute them on its own, so use Even split or edit the shares yourself until they sum to 100%. "Escalation failure" here means a task that failed during or after a handoff to a person, not a routing decision's own share of traffic.

Failure budget

500

Allowed failure rate 0.5%. About 16.67 failures a day over 30 days.

A 99.5% target over 100000 tasks buys 500 failures; 0 logged so far, 500 remaining.

This page never rolls the classes into one reliability percentage. A single number would hide which class is spending the budget.

Total remaining

500

Total observed

0

Budget by class

ClassShareBudgetObservedRemainingConsumedObserved rate95% intervalReading
task failure 40% 200 0 200 0% no scored count
tool failure 25% 125 0 125 0% no scored count
timeout 15% 75 0 75 0% no scored count
escalation failure 10% 50 0 50 0% no scored count
safety failure 10% 50 0 50 0% no scored count
Total 500 0 500

No scored count was given, so observed rates are not shown.

Export

totalBudget = volume * (100 - targetPct) / 100How?

How this is calculated

The error budget is the failure count a target completion rate buys: the Google SRE workbook's definition, "the error budget is 100% minus the SLO," applied to a task volume instead of a request count. A 99.5% target over 100,000 tasks buys 500 failures.

The split. Each class takes a share of the total budget, entered as a percentage and held internally as integer basis points so the sum check is exact rather than a decimal tolerance that three equal thirds can defeat. The shares of every non-invariant class must sum to within 1 basis point of 100%; a class marked a hard invariant drops to zero share, and any failure it takes is a breach rather than a budget draw. Its points return to the classes that can spend, which is why marking one changes the sum you need to hit.

Observed rates need a scored count. Failures typed into a class show its budget, remaining and consumed share right away. A rate and its interval need one more number: tasks scored so far. Without it, the tool refuses to guess a rate off the planned volume, because a window twelve days in reads differently from one at its end. With a scored count, each class's observed rate gets a Wilson interval (P-09, the same interval this suite uses elsewhere) against the class's allowed rate: the reading is over when the interval's lower bound clears the allowance, inside when its upper bound stays under it, and cannot tell at this sample when the allowance sits inside the interval.

Pace. With a days-elapsed figure, the tool reads a static daily pace from failures logged so far and asks how many days of the window that pace covers. This is not a burn-rate gauge: there is no live telemetry, no threshold and no alert, only the arithmetic stated inputs give.

Worked example. 99.5% over 100,000 tasks buys a 500-failure budget. Five classes at shares 40/25/15/10/10% split it into 200/125/75/50/50. If task failure logs 240 failures against 40,000 tasks scored, its remaining is -40 and its 95% Wilson interval sits above its 0.2% allowance: a reading of over, not a single "60% reliable" verdict for the whole system.

A step-by-step chain of tasks compounds differently: see the per-step compounding calculator for an independent-steps chain, or the correlated-failure simulator when steps share a cause. And a failure in one class can propagate into another before it is counted here. A release gate reads this page's remaining figure directly as evidence; see the release gate designer.

This budget is drawn against a target set elsewhere: the acceptable-error-rate calculator is usually where that target comes from. Once a class is over budget, the expected-cost-of-failure calculator turns the overage into a dollar figure, and the cost-per-successful-task calculator reads the same completion rate the other way, as what each success actually costs to reach.

Formula: totalBudget = volume * (100 - targetPct) / 100

Questions

What is a hard invariant, and why does marking one change the split?

A hard invariant is a class that may never spend budget: a prohibited action, or a legally required human decision that was skipped. Marking a class this way sets its share to zero and turns any observed failure on it into a breach rather than a consumed share. Because the target sets the total budget, a class that may never fail cannot also hold part of it, so the points it would have held return to the classes that can spend.

Why is there no single agent-reliability percentage?

A completion rate depends on who scores it and what a "class" means for a given system, so collapsing several failure classes into one number hides which class is actually spending the budget. This page keeps the split visible instead. A run of dependent steps compounds differently again, which is what the per-step compounding calculator and the correlated-failure simulator are for.

What is the difference between an SLA, an SLO and this budget?

An SLA is the contract with a penalty attached. An SLO is the internal target this page budgets against: a completion rate you are aiming to hold, with no external penalty of its own. The error budget is what an SLO permits to go wrong.

Why does the interval use tasks scored, not the planned volume?

A rate taken on the planned volume understates itself early in a window and narrows its interval past what the evidence supports. Tasks actually scored is the only honest denominator, which is also why the tool shows no rate at all until you type one.

Sources

  1. Google SRE Workbook, Implementing SLOs (error budget as 100% minus the SLO)Google SRE Retrieved
  2. OpenSLO specification (occurrences budgeting, rolling windows, good-over-total)OpenSLO Retrieved