Total remaining
500
INSTRUMENT | Reliability testing
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.
Showing your last valid result. Update the inputs above to recompute.
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
| Class | Share | Budget | Observed | Remaining | Consumed | Observed rate | 95% interval | Reading |
|---|---|---|---|---|---|---|---|---|
| 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.
totalBudget = volume * (100 - targetPct) / 100How?
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
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.
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.
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.
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.