Error Budget Calculator

An SLO is a promise; the error budget is what's left of it. Enter your target, your window, and the downtime you've taken so far, and see where you stand. Free, no signup, runs in your browser.

What an error budget is

An error budget is the amount of unreliability you're allowed before you break your own target. Flip an SLO around: if you're aiming for 99.9% uptime over a 30-day window, you're accepting 0.1% of downtime, which works out to 43 minutes 12 seconds. That 43 minutes is the budget. It's not a failure state to spend it; it's there to be spent. The point of naming it is that it turns a vague goal ("be reliable") into a concrete allowance you can make decisions against ("we have 12 minutes left this month, so hold the risky deploy").

How to calculate an error budget

The budget in time is simply (1 − SLO) × window length. Pick your window, convert it to minutes, and multiply by the fraction of downtime your SLO permits. A 99.9% SLO over 30 days is 0.001 × 43,200 minutes = 43.2 minutes. Over a 7-day window the same SLO gives about 10 minutes; over a year, roughly 8 hours 46 minutes. This calculator does that math and then goes one step further, comparing the downtime you've already logged against the budget to show what's left and whether you're on track.

How to read the burn rate

Burn rate is the consumption speed relative to a perfectly even spend. At burn rate 1.0 you land exactly on budget when the window closes. At 2.0 you run out halfway through. Google's SRE workbook suggests paging on sustained burn rates above 2, and treating anything above 10 as an emergency, since a 14x burn rate exhausts a 30-day budget in roughly two days. The practical value of the burn rate is that it separates "we had one bad day but we're fine for the month" from "we are bleeding budget and will breach in 48 hours if this continues."

One thing this calculator can't know: how the downtime was distributed. A budget burned by a single 12-minute outage and a budget burned by 144 five-second blips look identical here, but they call for different fixes. The first is usually an incident response problem, the second an infrastructure one.

Fast burn and slow burn

Mature error-budget alerting usually watches two speeds at once. A fast-burn alert fires when you're spending budget so quickly that a single incident could blow a big chunk of the window in hours; it's tuned to catch acute outages and it pages immediately. A slow-burn alert fires when a persistent low level of errors is quietly eroding the budget over days; it's tuned to catch the gradual degradation that no single incident would trigger. Watching only one speed leaves a gap: fast-burn alone misses slow leaks, slow-burn alone reacts too late to sudden failures.

Where the budget actually goes

In practice a chunk of every error budget is spent before mitigation even starts, on detection and escalation. If your checks run every 5 minutes and the first alert sits unread in an inbox for another 10, a 99.9% monthly budget is a third gone before anyone has typed a single command. Tightening check intervals and making alerts impossible to miss is often the cheapest budget recovery available, because it attacks the part of every incident that produces no value at all: the time between the thing breaking and anyone knowing.