Time to exhaustion is how long the remaining error budget will last if the current burn rate continues. It equals the SLO window multiplied by the fraction of budget left, divided by the burn rate. With 15% left on a 30-day SLO at 8×, the budget is gone in about 13.5 hours.
How do you calculate time to exhaust an error budget?
Burn rate says how fast the error budget is being used. Time to exhaustion turns that into a deadline: how long the budget left will last if nothing changes.
For a full budget, divide the SLO window by the burn rate:
time to exhaust = SLO window ÷ burn rateWhen part of the budget is already used, multiply by the fraction remaining:
time to exhaust = SLO window × fraction of budget remaining ÷ burn rateHow long does a full error budget last at each burn rate?
For a 30-day SLO with a full budget:
| Burn rate | Approximate time to exhaust a full budget |
|---|---|
| 0.5× | 60 days |
| 1× | 30 days |
| 2× | 15 days |
| 5× | 6 days |
| 10× | 3 days |
| 20× | 36 hours |
| 50× | 14 hours 24 minutes |
| 100× | 7 hours 12 minutes |
- 1×30 daysOn pace
- 2×15 daysSlow burn
- 5×6 daysSerious
- 10×3 daysUrgent
- 20×36 hoursFast burn
- 50×14 h 24 minSevere
- 100×7 h 12 minOutage
A burn rate of 0.5× would last 60 days, longer than the window itself. In practice, the window moves on first, so the budget is never used up at that rate.
How long does the remaining budget last?
The time left falls quickly as the budget runs down. For a 30-day SLO:
| Budget left | At 2× | At 10× | At 14.4× | At 50× |
|---|---|---|---|---|
| 100% | 15 days | 3 days | 50 hours | 14 h 24 min |
| 50% | 7.5 days | 36 hours | 25 hours | 7 h 12 min |
| 20% | 3 days | 14 h 24 min | 10 hours | 2 h 53 min |
| 10% | 36 hours | 7 h 12 min | 5 hours | 1 h 26 min |
Worked example: the Dispatch API
A logistics platform’s Dispatch API has a 99.9% request-success SLO over a rolling 30 days. After a faulty deployment, its failure rate rose to 0.8%, a burn rate of 8×. A day later, 85% of its error budget is used and 15% remains.
30 days × 0.15 ÷ 8 = 0.5625 days ≈ 13.5 hoursThe SLO is still met, but if the failure rate stays at 0.8%, it will be breached in about 13.5 hours. That is the time the team has to find the cause and stop the failures. The burn rate guide follows the same example through to the rollback.
Why is time to exhaustion only an estimate?
The formula assumes a constant burn rate and constant traffic. Real services rarely have either:
- Traffic changes: in a request-based SLO, a failure rate at peak traffic uses budget faster than the same rate overnight.
- The failure rate changes: an incident may get worse, or recover on its own.
- The window moves: in a rolling window, older failures leave as time passes and return headroom, which can stretch the real time to breach.
Treat the result as a deadline to plan against, not a prediction. Recalculate it as the burn rate changes.
Does a burn rate above 1× mean the SLO will breach?
Not necessarily. A burn rate above 1× indicates an unsustainable failure ratio if it continues for the whole window. It does not mean the service will breach within the next 30 days: the burn rate may fall, and in a rolling window, old failures keep leaving.
What matters is the combination: how much budget is left, and how fast it is going.
How do teams use time to exhaustion?
Time to exhaustion is most useful when compared with how long it takes to respond. If the budget will last 13 hours and a rollback takes 20 minutes once someone starts, there is time. If it will last 40 minutes and it takes 30 minutes to reach the right engineer, there is not.
- Under a few hours: alert on-call now and mitigate first, often by rolling back.
- About a day: alert on-call, investigate during working hours.
- Several days or more: open a ticket and fix the cause in planned work.
This is the same logic behind multi-window burn-rate alerting: each threshold matches an amount of budget used and the time left to act.
Frequently asked questions about error budget exhaustion
How do you calculate how long an error budget will last?
Multiply the SLO window by the fraction of budget remaining and divide by the current burn rate. With 50% left on a 30-day SLO at 10×, the budget lasts 30 × 0.5 ÷ 10 = 1.5 days.
How long does an error budget last at a 14.4× burn rate?
On a 30-day SLO, a full error budget lasts about 50 hours at 14.4×. That is why 14.4× over one hour is a common fast-burn alert: it means 2% of the budget used in that hour.
What happens when the error budget is exhausted?
The service has used its entire failure allowance for the window, and any further failures put it below its SLO. What the team does next is usually set out in an error budget policy.
Is time to exhaustion the same as time to SLO breach?
They are the same in the simplified model. In practice, a rolling window and changing traffic can make the real breach come later or sooner than the projection.
Key takeaways
- Time to exhaustion = SLO window × fraction of budget remaining ÷ burn rate.
- On a 30-day SLO, a full budget lasts 3 days at 10× and 36 hours at 20×.
- With little budget left, even a moderate burn rate leaves only hours.
- The result is an estimate; traffic and a rolling window both move it.