Error Budget Calculator
The SRE ledger — how many requests may fail, how many did, and how fast the allowance is burning.
Error Budget Calculator
Results recalculate instantly on every keystroke. Nothing you type is transmitted.
What this result does not account for
- One window, one binary good/bad split
- No multi-window alert windows modeled
In short: A 99.9% SLO over 1,000,000 requests budgets 1,000 failed ones — that is the whole allowance. Spend 300 and the burn rate reads 0.300000×: under budget pace, safe to ship. The error rate is 0.030000% against the 0.100000% allowance; cross the budget and the doctrine is to freeze features and fix reliability first.
Formula
budget = requests × (100 − SLO)% ··· burn = error rate ÷ (100 − SLO)%
An error budget turns a reliability target into a spendable allowance: the share of requests you are willing to fail, priced in counts rather than minutes. The burn rate divides your measured error rate by that allowance — 1× means consuming the budget at exactly the pace that exhausts it when the window closes, above 1× means the quiet week ahead is already spoken for. Vendors' downtime burns your budget too; the window does not care whose fault it was.
Worked Example
- Enter the SLO your team actually holds.
- Enter the requests in the window.
- Enter the requests that missed.
- Read the budget, the rate, and the burn.
Defaults: 99.9% SLO, 1,000,000 requests, 300 failed → budget 1,000, burn 0.300000×. Drive failures to 1,200 → the budget is gone at 1.200000× burn.
Strengths & Limits Of This Model
Where this engine is strong
- Burn rate derived against the live allowance
- Zero-budget SLO refused with reasoning
Where it stops
- No latency-SLO variant — availability only
Practical Use Cases
Release gating
ship or freeze, by arithmetic
SLO reviews
is the target even survivable
Vendor scorecards
their outages, your budget
Methodology & Editorial Standards
Computation runs in IEEE-754 double precision at full internal precision; rounding to two decimal places occurs strictly at the display layer, so no cumulative drift enters the result. All monetary outputs use accounting presentation — grouped thousands, two decimals, negatives in parentheses — so figures can be transcribed directly into a model or working paper. Division-by-zero and out-of-domain inputs return an em-dash rather than a misleading number.
This engine was reconciled against an independent reference implementation and hand-verified for the worked example above before release. Our full five-stage review process is published on the About Us page.
Disclaimer. This calculator is provided for informational and modelling purposes only and does not constitute financial, tax, legal, medical, or engineering advice. Verify all figures with a qualified professional before acting on them.
Error Budget Calculator — 8 Expert FAQs
8 analyst-written answers to the questions practitioners actually ask — optimised for voice and answer-engine retrieval.
How do I calculate an error budget?
Multiply total requests by the failure share your SLO permits: 1,000,000 requests at 99.9% gives 1,000 failed requests of budget. Spend fewer and the remainder funds risky releases; spend more and the policy is to stop features and repair reliability.
What is a burn rate?
Your measured error rate divided by the allowed error rate. A burn of 1× consumes the budget at exactly the pace that exhausts it at window's end; 2× exhausts it in half the window. Alerting doctrine pages on short windows at high burn — the famous 14.4× over an hour — and tickets on slower burns.
Why not alert on raw error rate?
Because the same 1% means different things at different SLOs: comfortable at 99%, a 10× burn at 99.9%. The budget context is what turns a number into a decision — which is the entire argument for burn rate over raw rate.
What happens when the budget is gone?
The working agreement kicks in: feature releases freeze while reliability work drains the debt, because shipping more change into a burning service spends budget you do not have. The page names the state rather than dressing it up.
Does provider downtime burn my budget?
Yes — your users experienced the failure inside your window, whatever the vendor's own SLA says. That asymmetry is why dependency lists and composite availability belong in every SLO conversation.
Is a request budget better than a minutes budget?
They measure different wounds: minutes miss partial degradations that fail one request in ten, and request counts miss total blackouts on quiet traffic. Mature teams run both — this page for the API, the downtime page for the window.
What SLO should I pick?
One your current traffic can survive and your users can feel. A 99.9% SLO on light traffic is a handful of errors; on a billion requests the same SLO is a million — plenty to absorb real incidents. Set it from user need, then check the budget arithmetic here before signing up.
Why is an SLO of 100% refused here?
A 100% objective leaves zero allowance — no budget to budget, no release to ship, no incident to survive. Reliability engineering starts by admitting a failure share; 99.99 with honest paging beats 100 as a slogan.