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)
- 50.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.
How fast you are spending what you have
With 50% of the error budget consumed at 25% of the way through the window, the burn rate is 2.00× — you are spending budget twice as fast as time is passing, and at this pace the budget will be gone at the halfway point of the window.
Burn rate is the derivative of error budget consumption, and it is what makes error budgets useful for alerting rather than merely for reporting. A budget report tells you where you stand. A burn rate tells you where you are heading.
The calculation
Burn rate = budget consumed (%) ÷ time elapsed (%) 50 ÷ 25 = 2.00×
Projected exhaustion (% of window) = 100 ÷ burn rate 100 ÷ 2 = 50% of the window.
Reading the scale:
- Below 1× — spending slower than time passes; the budget will outlast the window.
- Exactly 1× — perfectly on pace; the budget runs out precisely at the window's end.
- Above 1× — the budget exhausts early, and the projection says when.
- 10× — a 30-day budget consumed in three days.
Why alert on burn rate rather than errors
Alerting on a raw error threshold produces two failure modes, and burn-rate alerting fixes both.
A static threshold fires constantly during minor blips that consume trivial budget, training people to ignore it. It also stays silent during a slow degradation that is quietly eating the month's allowance.
Burn rate is normalised against what you can afford, so it fires in proportion to genuine risk. A brief spike that consumes 0.1% of the budget does not page anyone at 3 a.m.; a sustained elevation that will exhaust the month by Wednesday does.
Multi-window, multi-burn-rate alerting
The refinement Google's SRE practice recommends is to run several burn-rate alerts simultaneously, each pairing a rate threshold with a measurement window:
Fast burn — 14.4× over 1 hour (consuming 2% of a 30-day budget in an hour). Page immediately; something is badly wrong now.
Medium burn — 6× over 6 hours (5% of the budget). Page, but with less urgency.
Slow burn — 1× over 3 days (10% of the budget). A ticket rather than a page; something is degrading steadily.
Each alert is typically paired with a shorter confirmation window — requiring both the long and short window to breach — so that a condition which has already resolved does not keep paging.
The effect is that the severity of the response scales with how quickly the problem will actually cost you, which is a far better signal than the absolute error count.
Reading the result
The projection assumes the current rate continues unchanged, which is a straight-line extrapolation and rarely exactly true. Its value is as a decision prompt rather than a forecast: a 2× burn rate at the quarter mark means the pace must halve for the budget to survive the window.
A burn rate below 1× is not automatically good news. Consistently burning at 0.1× suggests the SLO is set far below what the system actually delivers, which means the budget provides no useful signal and the team may be being more conservative than the target requires.
Common mistakes
Alerting on a single burn-rate window. One threshold is either too noisy or too slow; use several.
Omitting the short confirmation window. Without it, a resolved incident continues to page while the long window still reflects it.
Extrapolating from a very short elapsed period. At 1% of the window elapsed, the denominator is tiny and the rate is extremely noisy.
Treating exhaustion as a deadline rather than a signal. The point is to change course before the budget is gone, not to note the moment it happens.
Having no agreed response. A burn-rate alert that nobody is empowered to act on is just a more sophisticated way of being ignored.