What an error budget is and why it exists
An error budget is the failure a service level objective explicitly permits. If you commit to 99.9% success, you have committed to a 0.1% failure allowance, and over a window with 100 million requests that allowance is 100,000 failed requests. Those failures are not a mistake to be eliminated; they are a resource to be spent.
That reframing is the entire point. Without it, reliability arguments have no arithmetic: the product team wants to ship, the operations team wants to freeze, and both positions are unfalsifiable. With a budget, the question becomes accounting. If 38% of the budget is left with two weeks of the window to run, there is room for a risky migration. If the budget is overspent, the policy — agreed in advance, not negotiated during the incident — says what stops.
Two SLI shapes are in common use and this calculator handles both. A ratio SLI counts good events against valid events: successful requests, requests served under a latency threshold, records processed without corruption. A time-based SLI counts good minutes against total minutes, which is what a traditional uptime SLA measures and what the uptime and SLA downtime calculator converts into hours per year. The budget in minutes reported here is the same quantity applied to the compliance window rather than to a calendar year.
The model comes from Google's site reliability engineering practice, where the error budget and the burn-rate alerting built on top of it were first written down. The specific alert thresholds this calculator derives — spend 2% of the budget in an hour, 5% in six hours, 10% in a day — are the ones set out in the SRE Workbook chapter on alerting.
The three quantities, and why burn rate is dimensionless
The budget is the easy part: multiply the allowed failure ratio by the number of valid events. Get the denominator right and everything else follows. “Valid events” excludes things you have agreed not to count — health checks, traffic from your own load tests, requests rejected for malformed input where rejection is correct behaviour. Every event you exclude shrinks both the denominator and, proportionally, the budget, so exclusions must be defined before the window starts rather than discovered during a bad week.
Consumption is failures observed divided by the budget. Above 100% you have breached, and the size of the overspend matters for the post-mortem even though the SLO is already missed.
Burn rate is where the design becomes elegant. Divide the error rate you are seeing right now by the error rate you could sustain forever — which is exactly the allowed failure ratio. The units cancel, so a burn rate of 1 means you are spending budget at precisely the speed the window replenishes it, whatever the SLO and whatever the traffic. A burn rate of 10 means you would consume a full window's budget in a tenth of a window. This is why burn rate, not error rate, is the right thing to alert on: a 0.5% error rate is catastrophic against a 99.99% SLO and unremarkable against a 99%.
The alert thresholds fall out of the same algebra. To detect the spend of a fraction f of the budget within an alert window of Walert hours, the burn rate must be f × W ÷ Walert, where W is the compliance window in hours. For a 30-day window that gives 0.02 × 720 ÷ 1 = 14.4 for the fast page and 0.05 × 720 ÷ 6 = 6 for the slower one — the published figures. A 28-day window scales them by 28/30, which is why the table above shows 13.44 and 5.6 at the default settings.
Pair each threshold with a short second window before you page. A 14.4× burn over one hour that has already stopped is not worth a page at 03:00; requiring the burn to still be elevated over the last five minutes resets the alert quickly once the incident ends.
Worked example: a 99.9% API over 30 days
An API serves 1,000,000 requests in a 30-day window and commits to 99.9% success. Halfway through the window, monitoring shows 500 failed requests and a current error rate of 0.1%.
- Allowed failure ratio. 1 − 0.999 = 0.001.
- Error budget. 0.001 × 1,000,000 = 1,000 failed requests for the window.
- Budget consumed. 500 ÷ 1,000 = 50%. Half the budget, half the window — exactly on plan.
- Budget remaining. 1,000 − 500 = 500 failures.
- Equivalent bad minutes. 30 days is 43,200 minutes, so 0.001 × 43,200 = 43.2 minutes of complete unavailability.
- Burn rate. 0.001 ÷ 0.001 = 1.0×. Break-even.
- Request rate. 1,000,000 ÷ (30 × 86,400) = 0.3858 requests per second.
- Failures per second. 0.3858 × 0.001 = 0.0003858.
- Time to exhaustion. 500 ÷ (0.0003858 × 3,600) = 360 hours, which is 15 days — precisely the half-window that remains. A burn rate of 1 always produces that answer when consumption and elapsed time agree.
Now change one number. If the error rate jumps to 1.0%, the burn rate becomes 0.01 ÷ 0.001 = 10×, failures arrive at 0.003858 per second, and the remaining 500 failures are gone in 500 ÷ (0.003858 × 3,600) = 36 hours. Ten times the burn, one tenth the time — the relationship is exactly reciprocal because the remaining budget has not changed.
How to read burn rate and budget consumption
Read consumption against elapsed time, not in isolation. Sixty per cent of the budget spent is comfortable on day 25 of a 28-day window and alarming on day 3. The single most useful dashboard panel is not the consumption figure but the projection: budget remaining plotted forward at the current rate, which is what the chart above draws.
Read burn rate against 1. Below 1, a full window at the current error rate finishes inside the SLO. Above 1, it does not. That statement is true by construction and needs no judgement, which is why burn rate is the safest number to put in an alert rule. What it does not tell you is whether you can afford the burn: a 3× burn with 90% of the budget left is survivable for days, while the same 3× burn with 5% left has hours in it. Alert on burn rate, decide on remaining budget.
Choosing the SLO target itself is a business decision, not an engineering one. Each additional nine costs roughly an order of magnitude more to deliver and removes an order of magnitude of budget, and past some point users cannot perceive the difference because their own network is less reliable than your service. Set the target just above the level at which users start complaining, and revisit it when the complaint pattern changes. If you are trying to justify the spend a higher target implies, put a number on the loss it avoids with the IT downtime cost calculator.
Where the service is composed of several dependencies, the achievable target is bounded by their product. Four dependencies at 99.99% each cannot support a 99.99% service, because the chain multiplies to 99.96%. Work that out before committing with the series and redundancy availability calculator.
Error budget by SLO target
| SLO | Allowed failure ratio | Failures per million requests | Bad minutes / 28 days | Bad minutes / 30 days |
|---|---|---|---|---|
| 99% | 0.01 | 10,000 | 403.20 | 432.00 |
| 99.5% | 0.005 | 5,000 | 201.60 | 216.00 |
| 99.9% | 0.001 | 1,000 | 40.32 | 43.20 |
| 99.95% | 0.0005 | 500 | 20.16 | 21.60 |
| 99.99% | 0.0001 | 100 | 4.03 | 4.32 |
| 99.999% | 0.00001 | 10 | 0.40 | 0.43 |
The bad-minutes column assumes the service is completely unavailable during those minutes. Partial degradation spends the budget more slowly, in proportion to the share of requests actually failing.
Pitfalls that make an error budget lie to you
- Counting the wrong denominator. Health checks and synthetic probes inflate the event count and therefore the budget. Define valid events before the window opens.
- Averaging over a window that hides the incident. A three-hour total outage inside a 30-day window is only 0.4% of the time; a 99.5% SLO survives it on paper while every user noticed. Multi-window burn-rate alerting exists precisely to catch this.
- Measuring at the load balancer. Requests that never reached your infrastructure — DNS failures, edge outages, client-side errors — do not appear in server-side counts, so the SLI overstates success. Client-side or probe-based measurement catches them.
- Using a calendar month as the window. Months differ in length and in how many weekends they contain, so the budget changes size between windows. A 28-day rolling window always holds four of each weekday.
- Treating a leftover budget as an obligation to spend. Deliberately degrading a service to use up budget is a misreading. An unspent budget is permission to take risk, not a requirement to.
- Setting a target you cannot measure to. A 99.999% SLO on a service handling 10,000 requests a month allows 0.1 failures. A single error breaches it, and the measurement is noise. Ratio SLOs need volume.
- Forgetting that burn rate depends on the current rate only. The exhaustion forecast assumes the present error rate continues unchanged. It is a projection under a fixed assumption, not a prediction.
Write the error budget policy before you need it
The calculator produces numbers; a policy turns them into decisions. Agree in advance, in writing and with the product owner's signature, what happens at each threshold. A common shape: below 50% consumed, ship freely; above 75%, require a reliability review for changes to the affected service; above 100%, freeze feature releases and direct engineering effort at reliability until the window rolls forward. Also decide who can grant an exception and on what grounds — usually a security fix or a regulatory deadline.
The value of writing it down early is that nobody is arguing about the rule and the incident at the same time. A policy negotiated at 100% consumption is not a policy.
Error budgets, SLAs and the rest of the reliability stack
Keep three terms distinct. An SLI is the measurement — the ratio you actually compute from telemetry. An SLO is your internal target for that measurement, and it is where the error budget comes from. An SLA is a contract with a customer, carrying financial consequences. Set the SLO tighter than the SLA, always: the gap is the margin in which you can detect and fix a problem before it costs money. A service selling a 99.9% SLA is commonly run to a 99.95% SLO for exactly this reason.
Error budgets complement rather than replace component reliability analysis. Mean time between failures and mean time to repair describe the physical behaviour of a system and are the natural inputs to an availability model; the budget describes what the business has agreed to tolerate. You need both, because a design can meet its availability target and still exhaust its budget through a small number of long incidents, or miss it while staying inside budget through many short ones.
For data services, availability is only half the obligation. The other half is how much data an incident may destroy, which is the recovery point objective — quantified with the RPO and RTO data-loss calculator. A replication design can hit its uptime SLO comfortably and still lose an unacceptable window of writes, and no amount of error budget covers that.