Error Budget Burn Rate
Compute how fast you are consuming your error budget and whether it will run out before the window ends.
Formula last reviewed 4 August 2026 · How we verify our calculators
Burn rate
2.00×
- Status
- ⚠ Will exhaust budget before window ends
- Budget gone at (% of window elapsed)
- 1250.0%
Updates live as you type
Frequently asked questions
It is how fast you are spending your error budget relative to the pace of time. Burn rate = budget consumed % ÷ time elapsed %. A rate of 1 means you’ll finish the budget exactly at the window’s end.
You’re consuming budget faster than time is passing, so you’ll exhaust it before the window ends. A burn rate of 2 (50% consumed at 25% elapsed) means the budget runs out at the halfway point if the pace holds.
Burn-rate alerting catches problems proportional to their severity — a fast burn pages you quickly, a slow burn warns gently — which reduces noise compared with a fixed error-count threshold. It’s the modern SRE alerting approach.
Teams often combine a fast window (e.g. 1 hour at a high burn rate) for acute incidents with a slower window (e.g. 6 hours) for gradual erosion, requiring both to fire to cut false alarms. This tool computes the core rate those alerts are built on.
The error budget comes from your SLO (100 − SLO). Burn rate tells you whether your current failure pace is sustainable within that budget for the compliance window — the early-warning signal before the budget is gone.
Are you spending your error budget too fast?
Knowing how much budget you've used isn't enough — what matters is the *pace*. Burn rate answers that: it's the error budget consumed divided by the fraction of the compliance window that has elapsed. A burn rate of 1 means you're exactly on track to use the whole budget right as the window closes. Above 1, you'll run out early; below 1, you'll finish with budget to spare.
Enter the % of budget consumed and the % of the window elapsed. The classic example: 50% consumed at 25% elapsed is a 2× burn rate, projecting budget exhaustion at the halfway mark — the tool flags this with a clear warning and the projected exhaustion point.
Burn rate is the foundation of modern SLO alerting. Instead of paging on a fixed error count, teams alert on burn rate so the urgency scales with severity: a sudden 14× burn pages immediately, while a gentle 2× over hours raises a ticket rather than waking someone at 3am for a slow, recoverable trend. Mature setups use multi-window alerts — a fast window (e.g. one hour) for acute incidents and a slow window (e.g. six hours) for gradual erosion — requiring both to fire before paging, which suppresses the false alarms a single-window threshold tends to generate during brief, self-resolving blips.
This is a genuinely advanced view of reliability that most calculator sites skip. Use it with the error-budget and SLO calculators to move from "how much is left?" to "will it last?" — the question that actually drives whether you keep shipping or stop to stabilise. A burn rate consistently above 1 across multiple review windows is a stronger signal than any single bad day, since it points to a systemic issue with the service's reliability rather than one unlucky incident.