Vibe Engines is free, interactive AI engineering & system design — runs in your browser. Pick a learning path
SLO Burn-Rate Calculator
Pick an SLO (99% to 99.99%), a window, and your current error rate: get the error budget in minutes and failed requests, the burn-rate multiple, time-to-exhaustion at the current pace, and the Google-SRE multiwindow alert table with the rows that would fire highlighted.
| Burn rate | Over | Error rate at your SLO | Action |
|---|---|---|---|
| 14.4× | 1 h | 1.44% | page |
| 6× | 6 h | 0.60% | page |
| 1× | 3 d | 0.10% | ticket |
An SLO quietly defines a spending account. A 99.9% target over 30 days means 0.1% of requests are allowed to fail; that allowance is the error budget, and it turns reliability from “never fail” into “fail within budget”. This calculator sizes the budget, measures how fast your current error rate spends it and shows which standard alerts would fire.
What it computes
budget = 1 − SLO as a fraction
budget mins = window days × 1,440 × budget
failures = requests per day × window days × budget
burn rate = current error rate / budget
exhausted in = window / burn rate never if burn = 0
alert at = burn threshold × budget as an error rate- SLO is one of five targets from 99% to 99.99%, and the window runs from 7 to 90 days.
- Current error rate is the share of requests failing now, from 0% to 5%.
- The status line reads sustainable below a burn of 1, a ticket-level problem below 6, page-worthy within hours below 14.4, and critical at 14.4 or more.
- The alert table converts the three reference burn rates, 14.4× over 1 hour, 6× over 6 hours and 1× over 3 days, into the error rate that would trigger each at your SLO, and highlights any row your current burn meets.
A worked example
The defaults are a 99.9% SLO over 30 days, a 0.2% error rate and 1,000K requests a day.
- Budget:
1 − 0.999 = 0.001, so30 × 1,440 × 0.001 = 43.2minutes, shown as 43 min. - Failures allowed:
1,000,000 × 30 × 0.001 = 30,000, shown as 30K. - Burn rate:
0.002 / 0.001 = 2.0×: “burning too fast, ticket-level problem”. - Exhausted in:
30 days / 2 = 15.0 days. - Alerts at this SLO: page at 1.44% errors over 1 hour, page at 0.60% over 6 hours, ticket at 0.10% over 3 days. Only the ticket row is highlighted.
| Same 0.2% errors at | Budget (30 days) | Burn rate | Exhausted in |
|---|---|---|---|
| 99% | 7.2 h | 0.2× | 150.0 days |
| 99.5% | 3.6 h | 0.4× | 75.0 days |
| 99.9% | 43 min | 2.0× | 15.0 days |
| 99.95% | 22 min | 4.0× | 7.5 days |
| 99.99% | 4.3 min | 20.0× | 36.0 h |
One error rate, five verdicts: comfortable at 99%, a page at 99.99%. That is why burn rate, not raw error rate, is the thing to alert on.
Assumptions and limits
- Constant error rate. Exhaustion assumes today’s rate continues and that the window’s budget is untouched so far.
- Minutes are an equivalence. The budget in minutes means full outage time; the same budget can be spent as a long trickle of partial errors.
- Thresholds assume 30 days. The 14.4×, 6× and 1× rows were derived for a 30-day window. In a 7-day window the same 1-hour burn spends about 8.6% of the budget, so retune them.
- One signal. Real alerts also need a short confirmation window and a minimum request volume, or low traffic produces noisy rates.
How to use the result
- Pick the SLO from user needs, then check the budget is large enough to deploy and experiment within; a tighter target than users notice only slows the team.
- Wire the table into alerting. Page on the fast rows, ticket on the slow one, so a 3 a.m. page always means real budget at risk.
- Attach a policy. When the budget runs out, freeze risky launches and spend engineering time on reliability until it recovers.
How it works
- Error budget = (1 − SLO) × window; shown as minutes and failed requests.
- Burn rate = current error rate ÷ (1 − SLO).
- Exhaustion = window ÷ burn rate.
- Alert table = Google SRE multiwindow reference; firing rows highlight.
Frequently asked questions
What is a burn rate?
The ratio between how fast you are consuming error budget and how fast you are allowed to. It is your current error rate divided by the error rate the SLO permits, which is 1 minus the SLO. A burn rate of 1 means you finish the window with exactly zero budget left. A burn rate of 10 means a 30-day budget is gone in three days. With this tool’s defaults, a 0.2% error rate against a 99.9% SLO is a burn rate of 2.
How big is an error budget really?
Small. A 99.9% SLO over 30 days allows about 43 minutes of complete outage, or the same amount spread as partial errors; 99.99% allows about 4.3 minutes, and 99% about 7.2 hours. The calculator also converts the budget into failed requests at your traffic: at a million requests a day, a 99.9% SLO allows 30,000 failures in 30 days, which is often the more intuitive number for a request-based service.
Why alert on burn rate instead of raw error rate?
A fixed error-rate threshold is either too twitchy, paging on brief blips, or too slow, missing slow leaks that drain the budget over days. Burn-rate alerting scales with the SLO automatically: page when you burn 14.4 times faster than sustainable over an hour, which spends 2% of a 30-day budget in 60 minutes, and open a ticket at 1 times over three days. The same rules then work for any SLO target.
Where do the 14.4× and 6× thresholds come from?
From the alerting guidance in Google’s Site Reliability Workbook, for a 30-day window: 14.4 times over 1 hour spends 2% of the budget and should page, 6 times over 6 hours spends 5% and should page, and 1 times over 3 days spends 10% and should open a ticket. Production setups pair each long window with a short one, about a twelfth as long, so an alert stops firing soon after the problem is fixed.
How long until my error budget runs out?
Divide the window by the burn rate, assuming the error rate stays where it is. At a burn rate of 2 a 30-day budget lasts 15 days; at 14.4 it lasts about 2.1 days; below 1 it is never exhausted within the window. If part of the budget is already spent, the remaining time is shorter in proportion, so subtract what the window has used so far. The calculator assumes a fresh, unspent budget.