Error Budget Calculator
Enter the availability you have committed to and the window it is measured over. The calculator returns the downtime that target permits, what remains after the minutes you have already spent, and — if you say how far into the window you are — the rate at which the budget is being consumed.
Every window length is editable, because none of them is fixed by anything except convention. A month can be twenty-eight, thirty or thirty-one days; a quarter can be ninety, ninety-one or ninety-two; a year can be three hundred and sixty-five or three hundred and sixty-six. If your agreement names a specific number of days, use that number.
The arithmetic
There is only one calculation. A window of d days contains d × 1440 minutes. An availability target of t per cent permits unavailability of (100 − t) per cent of that, so the allowed downtime is d × 1440 × (100 − t) ÷ 100.
Everything else on the page is derived from it. Remaining budget is the allowance minus what has been spent. The availability implied by the minutes spent is (window − spent) ÷ window. Burn rate is the fraction of the budget consumed divided by the fraction of the window elapsed: spend budget in exact proportion to time and the rate is one; spend half the month’s allowance in a tenth of the month and the rate is five.
Burn rate is the only figure here that says anything about the future, and it says it by assuming the recent past continues. Treat the projected exhaustion date as a description of the current trend rather than a forecast — most consumption arrives in lumps rather than at a steady trickle, and a single event can move the number from comfortable to exhausted in an afternoon.
What the window does to the answer
The same target yields wildly different allowances depending on the window it is measured over, which is why the window is the term people argue about in contract negotiations rather than the percentage.
A target measured yearly permits the whole allowance to be spent in one continuous event without breaching, provided the rest of the year is clean. The same target measured monthly forbids that, because the allowance for any one month is a twelfth of the size. Neither is more generous overall; they price different failure shapes. Long windows tolerate rare severe events and punish persistent small ones. Short windows do the reverse.
This matters for security operations specifically, because the disruption a security function causes tends to be lumpy — a blocking change that goes wrong, a rollout that destabilises a fleet, an emergency action taken under pressure. Measured yearly, a programme can look compliant while being unusable for two days. Measured weekly, the same programme breaches immediately. Pick the window that matches the failure pattern the users of your service actually care about.
Using it for an operations function
An error budget was invented for a service, but a security operations function is a service too, and its commitments can be stated as availability. Coverage during declared hours. A pipeline that is processing rather than silently stalled. An enforcement point that is enforcing. A triage queue that is being worked within the promised period. Each of those has a definition of “down” and therefore a budget.
The second use is more uncomfortable and more valuable: budget the disruption your own controls impose on everybody else. Minutes of legitimate traffic blocked, workstations rendered unusable, builds broken, logins prevented. That number is currently argued about in anecdotes in most organisations. Written as a budget, it becomes a constraint the security team accepts in public, which is the fastest route to being trusted with more consequential controls.
What should never be put into this calculator is a count of adversary-driven events. A budget is something you choose to spend. Attacks arrive whether or not you have allowance left, and an allowance of them is not a budget — it is a forecast that quietly implies somebody is permitted to stop caring once it is underspent.
What the number cannot do
An error budget does nothing on its own. The mechanism is the consequence attached to it — what the organisation agreed, in advance, would change when the budget is exhausted. Freeze the risky change class. Move people from project work to reliability work. Escalate at a defined level. If nothing happens when the budget runs out, the calculation was arithmetic practice.
Two further cautions. A budget measured against a target nobody chose deliberately is theatre; the target should come from what the users of the service actually need, not from the number of nines that sounded impressive in a document. And a budget that is never spent is not a triumph — it means the target was set below the delivered service, so it constrains nothing and tells you nothing.
Nothing you type here leaves your browser. The page performs a multiplication locally; it makes no network requests, stores nothing and has no analytics. The self-test line inside the panel re-checks the calculation against known values every time the page loads, and if any check fails the tool says so instead of showing you a number.