Glossary
Error budget
An error budget is the amount of unreliability an SLO permits, treated as a resource that the team can spend.
The error budget formula is 100% minus the SLO, applied to the window the SLO is measured over. At 99.9% over 28 days, 0.1% of 40,320 minutes is 40m 19s: the amount of failure the team has explicitly agreed is acceptable. Measured in requests instead of time, the same objective allows 1,000 failures in every million. Framing it as a resource rather than as a failure is the entire trick, because it turns reliability from a matter of opinion into a matter of arithmetic.
It works because it makes the trade-off explicit in both directions. A team with budget remaining can ship aggressively; a team that has spent it stops feature work and spends the next sprint on reliability instead. That rule has to be agreed in advance, when nobody is under pressure, or it will be renegotiated the first time it is inconvenient.
Burn rate is how fast the budget is being spent, relative to the pace that would use it up exactly at the end of the window. A burn rate of 1 spends a 28-day budget in 28 days; a burn rate of 10 spends it in under three days. That is why teams alert on burn rate rather than on single errors: a fast burn needs someone now, while a slow one can wait for working hours but still has to be fixed before the window closes.
The other half of the idea is less often used and just as valuable: consistently finishing a period with most of the budget unspent means the objective is too strict. Reliability that nobody asked for is bought with velocity that someone did, and an untouched error budget is the clearest available evidence that the target should be relaxed.
| SLO | Error budget per 28 days | Error budget per 30 days |
|---|---|---|
| 99% | 6h 43m 12s | 7h 12m |
| 99.5% | 3h 21m 36s | 3h 36m |
| 99.9% | 40m 19s | 43m 12s |
| 99.95% | 20m 10s | 21m 36s |
| 99.99% | 4m 2s | 4m 19s |
Questions
What is an error budget?
The amount of failure a service level objective allows over its window. At 99.9% over 28 days it is 40m 19s of downtime, or 1 failed request in every 1,000. While budget remains, the team ships; once it is spent, reliability work comes first.
How do you calculate an error budget?
Subtract the SLO from 100% and apply the result to the window. A 99.9% objective leaves 0.1%, and 0.1% of 40,320 minutes, the minutes in 28 days, is 40.32 minutes, or 40m 19s. For an SLO counted in requests, the same 0.1% is 1,000 failed requests in every million.
What happens when the error budget runs out?
Whatever the team agreed in advance, which is the point of agreeing it in advance. The common policy is a feature freeze: releases stop, except for reliability fixes, until the budget recovers as the window rolls forward. Without an agreed policy, a spent budget is only a number on a dashboard.
What is an error budget burn rate?
The speed the budget is being spent, relative to the pace that would use it up exactly at the end of the window. A burn rate of 1 is on pace; a burn rate of 10 spends a 28-day budget in under three days. Alerting on burn rate pages people for a fast burn and leaves a slow one for working hours.
What is the difference between an error budget and an SLO?
The SLO is the target, such as 99.9% of requests succeeding. The error budget is what the target leaves over, the 0.1% that is allowed to fail. They are one number read from opposite ends, but the budget is the version a team can plan with, because it says how much risk is still available.
Uptimely records every outage on each monitor's status timeline, so the downtime spending your error budget is measured rather than estimated.
Start monitoring free →Related terms
Part of the Uptimely monitoring glossary — plain definitions of the vocabulary uptime monitoring, incident response and status pages are discussed in. Something here read wrong to you? Email support@getuptimely.com.