Rex says
The fast lane for the math you almost remember from school. Type the numbers, get the answer, move on with your day.
Try a scenario
Click to load — tweak from there.Inputs
Result
Current burn rate (×)
15.00
Days until budget exhausted
1.6
Allowed error rate
0.100%
Budget remaining
80.0%
Psst — share this and help Rex grow
One click, a permanent link with your numbers baked in.
How to use this
- 1Enter slo target (%).
- 2Enter slo window (days).
- 3Enter current observed error rate (%).
- 4Enter budget already consumed this window (%).
- 5Read your current burn rate (×) on the right — it updates as you type.
- 6Hit Share to keep the scenario or send it to someone.
About this calculator
An error budget is the inverse of your SLO — if your target is 99.9% availability, your error budget is the 0.1% of requests or time you're allowed to fail within the period. Burn rate measures how fast you're consuming that budget relative to a steady, even-pace consumption, and it's the metric behind Google SRE-style multi-window alerting: a burn rate of 1.0 means you're on track to exhaust the budget exactly at period end, while a burn rate of 10 means you'll exhaust a 30-day budget in 3 days if the current error rate continues. This calculator takes your SLO target, the time window, and your current observed error rate to compute burn rate and time-to-exhaustion, which is the number that should actually drive paging decisions — a short burst at high burn rate deserves a page, while the same total error count spread evenly across a month often doesn't.
Worked example
Using the values the calculator loads with:
Inputs
- SLO target: 99.9 %
- SLO window: 30 days
- Current observed error rate: 1.5 %
- Budget already consumed this window: 20 %
Results
- Current burn rate (×): 15
- Days until budget exhausted: 1.6
- Allowed error rate: 0.100%
- Budget remaining: 80.0%
What each field means
Inputs
- SLO target (%)
- The slo target used in the calculation, measured in %. Starts at 99.9 % so you have a working example on load. Accepted range: 90–99.999 %.
- SLO window (days)
- The slo window used in the calculation, measured in days. Starts at 30 days so you have a working example on load.
- Current observed error rate (%)
- The current observed error rate used in the calculation, measured in %. Starts at 1.5 % so you have a working example on load. Accepted range: 0–100 %.
- Budget already consumed this window (%)
- The budget already consumed this window used in the calculation, measured in %. Starts at 20 % so you have a working example on load. Accepted range: 0–100 %.
Results
- Current burn rate (×)
- Returned as a decimal number and shown as the headline result. It recalculates instantly whenever you change an input, so you can compare scenarios without reloading.
- Days until budget exhausted
- Returned as a decimal number. It recalculates instantly whenever you change an input, so you can compare scenarios without reloading.
- Allowed error rate
- Returned as a percentage. It recalculates instantly whenever you change an input, so you can compare scenarios without reloading.
- Budget remaining
- Returned as a percentage. It recalculates instantly whenever you change an input, so you can compare scenarios without reloading.
FAQ
What burn rate should trigger a page versus a ticket?
Google's SRE workbook recommends a fast-burn alert around 14.4x sustained over 1 hour (would exhaust a 30-day budget in about 2 days) paired with a slow-burn alert around 6x sustained over 6 hours, using multi-window checks so brief blips don't page unnecessarily. Anything under roughly 1-2x burn rate is generally a next-business-day ticket, not a wake-someone-up event.
What happens once the error budget is fully consumed?
Most SRE practices freeze non-critical feature releases once the budget hits zero for the period, redirecting engineering effort to reliability work until the budget resets, and require director/VP sign-off to override the freeze. This is the mechanism that actually forces the organizational trade-off between shipping speed and reliability instead of leaving it as an abstract debate.
Should error budgets be measured by request count or by time?
Request-based budgets (percentage of failed requests) suit high-traffic services and give more statistical stability; time-based budgets (minutes of full outage) suit low-traffic or batch services where request volume is too sparse or spiky to be a reliable signal. Pick whichever unit matches how your users actually experience and would describe an outage.
Accuracy and limitations
- Results are rounded for display; the underlying calculation keeps full precision.
- Very large or very small inputs may hit floating-point limits in the browser.
- Inputs outside the accepted range are clamped rather than rejected.
Related tools
Cite this calculator
Writing about this topic? Grab a citation — every link helps keep these tools free.
RevenueLab. (2026). Error Budget Burn Rate Calculator. Retrieved from https://www.revenuelab.fyi/toolbox/error-budget-burn-rate
<p>Source: <a href="https://www.revenuelab.fyi/toolbox/error-budget-burn-rate" target="_blank" rel="noopener">Error Budget Burn Rate Calculator — RevenueLab</a> (2026).</p>
Source: [Error Budget Burn Rate Calculator — RevenueLab](https://www.revenuelab.fyi/toolbox/error-budget-burn-rate) (2026).