Error Budget Calculator
An unspent budget means you are shipping too cautiously.
Work out Error Budget. An unspent budget means you are shipping too cautiously. States the assumption instead of hiding it.
Error budget remaining
49.1%
21.2 of 43.2 minutes · burn rate 1.27
A burn rate of 1 means the budget is being consumed at exactly the pace that would exhaust it on the last day of the window, which is the intended outcome rather than a warning. The idea that makes error budgets useful is that spending them is allowed: a team consuming almost none of its budget is shipping too cautiously, and that is a failure of a different kind rather than an achievement. The budget converts an argument between the people who want to ship and the people who want stability into a shared number, and the policy attached to it — freeze releases at zero — is agreed in advance rather than negotiated during an incident.
How the Error Budget Calculator works
Error budget remaining against a service level objective, with the burn rate and a projected exhaustion date. The idea that makes budgets useful is that spending them is allowed — a team consuming almost none of its budget is being too careful to ship.
Also known as: error budget · slo · sli · burn rate sre · service level objective · error budget policy · budget exhausted · reliability budget · sre metrics · release freeze
Unreliability as a resource
An objective of 99.9% over thirty days is not a promise of perfection — it is an allowance of 43.2 minutes. The error budget reframes that allowance as something to spend rather than something to fear.
The consequence is the useful part. A team consuming almost none of its budget is not exceptional; it is shipping more cautiously than the target requires, and paying for that caution in features not delivered.
It converts a recurring argument — the people who want to ship against the people who want stability — into a shared number that both sides agreed to in advance. That is most of why the idea has spread well beyond the organisations that invented it.
Burn rate, and alerting on it
Burn rate compares consumption against the pace that would exactly exhaust the budget at the end of the window. A rate of 1 is on track. A rate of 2 exhausts the budget halfway through.
Alerting on burn rate catches something that per-incident alerting misses: a slow degradation that never trips a threshold and would still consume the month by the end of it.
A rolling window is generally better than a calendar one. A monthly reset creates an incentive to take risks on the last day of a bad month, and a rolling window has no such cliff.
Choosing an objective people can live with
The most common mistake is setting an objective above what users can perceive. Availability beyond the point anyone notices costs a great deal and buys nothing measurable.
The internal objective should also be stricter than any contractual agreement, so the budget runs out and triggers a response before credits are owed. Setting them equal means the first breach is a commercial problem rather than an engineering signal.
Measuring the budget in requests rather than minutes is frequently better. A failure affecting 1% of requests for an hour is not the same event as total unavailability for an hour, and only a request-based budget can tell them apart.
Where to go next
The Error Budget question rarely arrives on its own. These are the ones that usually come with it:
- Uptime SLA Calculator — Each nine divides the allowance by ten.
- MTTR and Availability Calculator — Detection is usually the biggest share and the cheapest to fix.
- Downtime Cost Calculator — Lost revenue is rarely the largest line.
- Ring Size Calculator — Finger measurement to US, UK, EU and Japanese sizes.
Frequently asked questions
What is an error budget?
The permitted unreliability implied by an objective. A 99.9% SLO over 30 days allows 43.2 minutes of failure, and that allowance is a resource to spend rather than a limit to fear.
What is burn rate?
How fast the budget is being consumed against the pace that would exactly exhaust it at the end of the window. A burn rate of 1 is on track; 2 means the budget will run out halfway through.
What happens when the budget is exhausted?
Whatever the policy says, agreed in advance. The usual response is to freeze feature releases and spend the time on reliability until the budget recovers — the value is in agreeing it before an incident rather than during one.
Why is an unspent budget a problem?
Because it means the team is shipping more slowly than the reliability target requires. Perfect availability against a 99.9% objective is over-delivery paid for in features not shipped.
How do I choose an SLO?
From what users actually notice, not from what sounds impressive. An objective set above what customers can perceive costs a great deal and buys nothing, and it is the most common mistake in setting one.
Should the SLO match the SLA?
The internal objective should be stricter than the contractual agreement, so the budget runs out before any credits are owed. Setting them equal means the first breach is a commercial problem rather than an engineering signal.
Who owns the error budget?
Shared between the people building and the people operating, which is the point. It replaces an argument about whether to ship with a number both sides agreed to in advance.
What is a burn rate alert?
An alert on the rate of budget consumption rather than on any single failure. It catches a slow degradation that never trips a threshold but would exhaust the budget by month end.
Should the budget reset every month?
A rolling window is more common in practice, because a calendar reset creates an incentive to take risks on the last day of a bad month. Rolling windows have no such cliff.
What if we exhaust the budget every month?
Either the objective is set higher than the system can deliver, or reliability work is genuinely being deferred. Both are real answers and the budget forces the conversation rather than settling it.
Do error budgets work for small teams?
The arithmetic does; the ceremony often does not. A small team benefits from knowing that 99.9% permits 43 minutes a month without needing a formal policy document around it.
Can an error budget be measured in requests rather than time?
Yes, and it is frequently the better measure. A failure affecting 1% of requests for an hour is not the same as total unavailability for an hour, and a request-based budget captures the difference.
Put this calculator on your own site
Free to use, on any site, commercial or not. Paste this where you want it to appear. It is a plain iframe, so it works in WordPress, Squarespace, Wix, Webflow, Ghost and anything else that accepts HTML.
<iframe src="https://www.thecalclibrary.com/embed/error-budget-calculator" width="100%" height="640" style="border:1px solid #e2e8f0;border-radius:12px" loading="lazy" title="Error Budget Calculator"></iframe>
<p style="font:13px/1.5 system-ui,sans-serif;margin:6px 0 0;color:#64748b">Powered by <a href="https://www.thecalclibrary.com/error-budget-calculator" style="color:#64748b">Error Budget Calculator</a> from The Calc Library</p>The only condition is that the credit line below the frame stays in place. That one line is what pays for the tool being free — it is how anyone else finds it.
Related calculators
Uptime SLA Calculator
Each nine divides the allowance by ten.
OpenMTTR and Availability Calculator
Detection is usually the biggest share and the cheapest to fix.
OpenDowntime Cost Calculator
Lost revenue is rarely the largest line.
OpenRing Size Calculator
Finger measurement to US, UK, EU and Japanese sizes.
Open