Error Budget Calculator: SLO Error Budget, Burn Rate and Downtime Allowance
Set your SLO and window to see the budget in real units, then enter what you have already spent to get the current burn rate, the time left before the budget is gone, and the exact error rates to put in your alert rules.
Error budget calculator
LiveSpent so far (optional)
What an error budget calculator does
An error budget is the amount of unreliability your SLO permits, and it equals one minus the SLO target applied across the compliance window. A 99.9% SLO over a 30 day window allows 43 minutes 12 seconds of downtime, or one failed request in every thousand. Burn rate measures how fast you are spending that budget against the pace that would use it up exactly at the end of the window, so a burn rate of 1 lasts the full 30 days and a burn rate of 10 empties the same budget in 3 days.
The arithmetic is simple enough to do on paper. The reason a calculator earns its place is that the two inputs people get wrong are the window and the units, and both change the answer by an order of magnitude. Quoting a 99.9% target without saying whether it is measured over a week or a quarter is quoting nothing: the same percentage buys 10 minutes in one case and just over 2 hours in the other.
The second half of the job is turning a static allowance into an operational signal. A budget you check at the end of the month tells you what already happened. Burn rate tells you what is happening now, which is the number worth alerting on, and it is the only form of the budget that gives your team time to act while the incident is still running.
The two formulas
Error budget
(1 - SLO) x window
Window is either a duration or a count of valid requests.
Burn rate
observed error rate / (1 - SLO)
Same thing as budget consumed divided by window elapsed.
Time to exhaustion
window / burn rate
From a full budget. From a partial one, scale by what is left.
The same target buys very different amounts of failure
How much downtime each SLO allows
These figures use rolling windows of whole days, which is how the Google SRE workbook frames an error budget and how most SLO tooling implements one. That makes a month 30 days here, matching the SLA calculator. The uptime calculator uses a 365 day year with a month defined as a twelfth of it, so its monthly figure for 99.9% is 43 minutes 48 seconds rather than 43 minutes 12 seconds. Both are correct. They answer slightly different questions, and the difference is worth knowing before you quote either number in a contract.
| SLO target | 7 days | 28 days | 30 days | 90 days |
|---|---|---|---|---|
| 99% | 1h 40m | 6h 43m | 7h 12m | 21h 36m |
| 99.5% | 50m 24s | 3h 21m | 3h 36m | 10h 48m |
| 99.9% | 10m 5s | 40m 19s | 43m 12s | 2h 9m |
| 99.95% | 5m 2s | 20m 10s | 21m 36s | 1h 4m |
| 99.99% | 1m | 4m 2s | 4m 19s | 12m 58s |
| 99.999% | 6 seconds | 24 seconds | 26 seconds | 1m 18s |
Read across a single row and the case for a longer window becomes obvious. A quarterly budget absorbs one bad afternoon without drama, where the same incident against a 7 day window looks like a crisis. Read down the 30 day column instead and you can see where human response stops working. At 99.9% you can notice a problem, discuss it, and still roll back inside the allowance. At 99.99% the entire month is 4 minutes 19 seconds, which is less time than most teams take to acknowledge a page, so recovery has to be automatic before the target is even plausible.
The same outage costs different amounts depending on how you count
Downtime minutes or failed requests
A time based budget counts minutes the service was unavailable. A request based budget counts individual requests that failed. Teams often assume these are two ways of saying the same thing, and for a service with perfectly flat traffic they roughly are. Real traffic is not flat, and that is where they separate.
Take a 10 minute outage. Measured in time, it costs the same whether it lands at 3am or at your busiest hour of the week, because 10 minutes is 10 minutes. Measured in requests, the 3am version might cost a few hundred failures while the peak version costs tens of thousands. The request based reading is the one that tracks what customers actually experienced, which is why user facing services are usually better served by counting events rather than minutes.
The trap runs the other way for low traffic services. Look at the top right of the table below: at 99.99% against 10,000 requests in the window, the entire budget is a single request. You cannot meaningfully measure that target, because one failure puts you exactly at the line and two puts you under it. The budget is smaller than the granularity of the thing you are counting, so the number will swing wildly for reasons that have nothing to do with reliability. Either lengthen the window until the count is large enough to be stable, or measure that service in time instead.
| SLO | 10K | 100K | 1M | 10M |
|---|---|---|---|---|
| 99% | 100 | 1,000 | 10,000 | 100,000 |
| 99.5% | 50 | 500 | 5,000 | 50,000 |
| 99.9% | 10 | 100 | 1,000 | 10,000 |
| 99.95% | 5 | 50 | 500 | 5,000 |
| 99.99% | 1 | 10 | 100 | 1,000 |
Failed requests allowed, by SLO target and the number of valid requests served in the window.
A ratio, so it means the same thing at every SLO
What burn rate actually measures
Burn rate normalizes the error rate against the budget, which is what makes it portable. An error rate of 1% is catastrophic for a 99.99% service and merely bad for a 99% one. Expressed as burn rate, that same 1% is 100x in the first case and 1x in the second, and the number now carries its own urgency without anyone having to remember which target applies. The figures below are for a 99.9% SLO over 30 days, and the first, second, fifth and last rows reproduce the reference table in the Google SRE workbook exactly.
| Burn rate | Error rate at 99.9% | Budget gone in | What it means |
|---|---|---|---|
| 1x | 0.1% | 30 days | Exactly on pace. The budget runs out at the moment the window closes. |
| 2x | 0.2% | 15 days | Half the window left when the budget is gone. |
| 3x | 0.3% | 10 days | The rate the workbook treats as a ticket, not a page. |
| 6x | 0.6% | 5 days | Consumes 5% of the budget in 6 hours. Worth paging on. |
| 10x | 1% | 3 days | A clearly degraded service. |
| 14.4x | 1.44% | 2 days 2 hours | Consumes 2% of the budget in 1 hour. The fastest page threshold. |
| 36x | 3.6% | 20 hours | Spends 5% of a 30 day budget in a single hour. |
| 1000x | 100% | 43 minutes | Total outage. Everything fails, so the whole month is gone in 43 minutes. |
The bottom row is the one that reframes the whole exercise. A service that is completely down burns at 1000x, and a 30 day budget at 99.9% survives that for 43 minutes. That is the real meaning of three nines: not that you get 43 minutes of leisurely degradation spread across the month, but that one total outage lasting three quarters of an hour has spent the entire year to date allowance for that window. It is also why the difference between a 1 minute and a 5 minute check interval is not a detail.
Alerting when the SLO is already missed is alerting too late
The alert rules to actually configure
The Google SRE workbook recommends alerting on burn rate across two windows at once, with a long window that decides whether the burn is serious and a short window that decides whether it is still going on. The workbook is explicit about why the short window exists: it was added so the alert fires "only when we're actively burning through the budget, thereby reducing the number of false positives". Without it, the long window keeps remembering an incident that has already been fixed and the alert keeps paging someone about a problem that is over.
| Severity | Long window | Short window | Burn rate | Budget consumed if sustained |
|---|---|---|---|---|
| Page | 1 hour | 5 minutes | 14.4x | 2% |
| Page | 6 hours | 30 minutes | 6x | 5% |
| Ticket | 3 days | 6 hours | 1x | 10% |
Those burn rates are the part everyone quotes. The part almost nobody publishes is what they mean in the units you have to type into an alert rule, because a monitoring system wants an error rate threshold, not a multiplier. The table below does that conversion for the common targets. Find your SLO row, and the three right hand columns are the error rates that correspond to the three alert tiers above.
| SLO target | Error budget | Page at 14.4x (1h / 5m) | Page at 6x (6h / 30m) | Ticket at 1x (3d / 6h) |
|---|---|---|---|---|
| 99% | 1% | 14.4% | 6% | 1% |
| 99.5% | 0.5% | 7.2% | 3% | 0.5% |
| 99.9% | 0.1% | 1.44% | 0.6% | 0.1% |
| 99.95% | 0.05% | 0.72% | 0.3% | 0.05% |
| 99.99% | 0.01% | 0.144% | 0.06% | 0.01% |
| 99.999% | 0.001% | 0.0144% | 0.006% | 0.001% |
Read the 99.99% row and a practical limit appears. To page at 14.4x you need to detect a sustained error rate of 0.144% over an hour, and to raise a ticket at 1x you need to resolve 0.01%. On a service handling a thousand requests an hour, 0.144% is one and a half requests, so the signal is mostly noise. High targets need high traffic before burn rate alerting behaves, which is the same small numbers problem that shows up in the request based budget table above.
Your budget can be smaller than your blind spot
Check interval sets a floor on the SLO you can claim
An outage that starts one second after a check runs is invisible until the next check fires. So the worst case detection delay is one full check interval, and the average across many incidents is half of one. That delay is not a rounding error against a small budget, it is a share of the budget, and at the higher targets it is most of it. The table gives one worst case detection delay as a percentage of the entire 30 day budget.
| SLO target | Budget, 30 days | 30 second checks | 1 minute checks | 5 minute checks | 10 minute checks |
|---|---|---|---|---|---|
| 99.9% | 43m 12s | 1.2% | 2.3% | 11.6% | 23.1% |
| 99.95% | 21m 36s | 2.3% | 4.6% | 23.1% | 46.3% |
| 99.99% | 4m 19s | 11.6% | 23.1% | 115.7% | 231.5% |
| 99.999% | 26s | 115.7% | 231.5% | 1,157% | 2,315% |
Anything over 100% is a target you cannot honestly report against at that interval. At 99.99% with 5 minute checks, a single outage can consume 116% of the monthly budget before your monitoring has looked twice, so the first data point you get already tells you the month is lost and nothing you measured explains when it started. Five nines is worse: at 26 seconds a month, even a 30 second check is coarser than the entire allowance, which is why every published five nines commitment leans on redundancy and automatic failover rather than on anyone watching.
The rule that falls out of the table is simple. Pick the interval first, then pick the tightest SLO whose budget is comfortably larger than one interval, ideally by a factor of ten or more so a single detection delay costs a slice rather than the whole thing. At 30 second checks that lands you at 99.9% or 99.95% and both are honest. Claiming four nines on 5 minute checks is not a stretch, it is a measurement you have no way to make. The same reasoning drives the choice of how often to check a website, and it is why the interval question is really an SLO question wearing different clothes.
Uptimehub runs checks as often as every 30 seconds from 6 regions, with a failure confirmed from a second region before it counts, so the timeline you get back is precise enough to reconcile against a budget this size. That reconciliation is the part teams usually discover they are missing: the budget arithmetic is easy, and the evidence for what you actually spent is not.
Measure the budget you are actually spending, at an interval fine enough to see it.
Questions
Error budget questions people actually ask
How do you calculate an error budget?
Subtract the SLO from 100% and apply the result to the compliance window. A 99.9% SLO leaves 0.1%, and 0.1% of 30 days is 43 minutes 12 seconds. For a request based SLO, apply the same 0.1% to the number of requests served in the window, so a million requests allows a thousand failures. The window matters as much as the target.
What is the error budget formula?
Error budget equals one minus the SLO target, multiplied by the length of the compliance window. Written out for time, that is (1 - SLO) x window duration. Written out for requests, it is (1 - SLO) x total valid requests. Both express the same idea: the SLO defines the failure you have already agreed to tolerate, and the budget is that failure measured in real units.
What is error budget burn rate?
Burn rate is how fast you are consuming the budget relative to the pace that would spend it evenly across the window. A burn rate of 1 uses the entire budget exactly as the window closes. A burn rate of 2 empties it in half the time. Because it is a ratio, the same burn rate means the same urgency at any SLO target, which is what makes it useful for alerting.
How is burn rate calculated?
Divide the observed error rate by the error budget. At a 99.9% SLO the budget is 0.1%, so an observed 1% error rate is a burn rate of 10. The equivalent form is to divide the fraction of budget consumed by the fraction of the window elapsed: 20% of the budget gone one quarter of the way through a month is a burn rate of 0.8, which is on track.
What happens when the error budget is exhausted?
That is decided in advance by an error budget policy, not in the moment. The Google SRE workbook example halts all changes and releases other than P0 issues and security fixes until the service is back inside its SLO. The point is that the consequence is agreed while everyone is calm, so an overspent budget triggers a pre-committed decision instead of an argument.
Why do burn rate alerts use two windows?
The long window decides whether the burn is significant and the short window decides whether it is still happening. Google adds the short window specifically to reduce false positives, because a long window keeps remembering an incident that already ended and will keep the alert firing after recovery. Requiring both windows to breach means the alert clears soon after the service does.
Should the error budget window be rolling or calendar?
A rolling window, usually 28 or 30 days, is the better default because it never resets your problems away. A calendar month hands a team that burned its whole budget on the 29th a clean slate on the 1st, which rewards waiting rather than fixing. Calendar windows are mostly useful when the budget has to line up with a contractual SLA that is billed monthly.
What is the difference between an SLO and an error budget?
They are the same number seen from opposite sides. The SLO is the share of requests or time that must succeed, and the error budget is the share that is allowed to fail. Stating it as a budget changes the conversation, because a target invites teams to aim for 100% while a budget makes unspent reliability look like a resource that could have bought a faster release cadence.
Keep reading
Where to go next
This page is the calculator. For the concept behind it, including what belongs in an error budget policy and the mistakes teams make when setting their first one, read error budgets in SRE. If you are still deciding which target to commit to, SLA compared with SLO and SLI covers which of the three is a contract and which is an internal goal, and the SLA calculator works out what a chain of dependencies lets you promise in the first place. For the allowance arithmetic across more levels and periods, use the uptime calculator, and for tracking a target continuously rather than at month end, see SLA monitoring.
Track the budget while there is still time to spend it well
Checks every 30 seconds from 6 regions, confirmed from a second region before a failure counts, so your burn rate is based on real incidents rather than flapping.