A fast burn uses a large share of an error budget in minutes or hours, usually after a faulty deployment or an outage. A slow burn uses it steadily over days or weeks, at a rate only a little above sustainable. Both can breach an SLO, and they need different alerts.
What is the difference between a fast burn and a slow burn?
Error-budget consumption can happen rapidly or gradually. These two patterns are called fast burn and slow burn, and they are measured with error-budget burn rate: how fast the budget is being used compared with the pace the SLO allows.
- Fast burn: 20× from day 10, the rest of the budget gone ~30 hours later
- Slow burn: 1.5× all month, budget gone on day 20
- 1×: the budget used exactly by day 30
| Fast burn | Slow burn | |
|---|---|---|
| Typical burn rate | 10× and above | A little above 1×, such as 1.5× to 3× |
| Full 30-day budget gone in | 3 days or less | 10 to 30 days |
| Typical causes | Faulty deployment, outage, bad configuration | Intermittent defect, slow dependency, creeping latency |
| How it is noticed | Error spikes and user reports | Often only when the budget report looks low |
| Example alert | 14.4× over 1 hour and 5 minutes | 1× over 3 days and 6 hours |
| Response | Alert on-call now; mitigate, often by rollback | Ticket; find and fix the defect in planned work |
What is a fast burn?
A fast burn occurs when a service consumes a significant portion of its error budget over a relatively short period. Examples include:
- A faulty application deployment causing widespread API failures.
- A database connection problem affecting customer transactions.
- A configuration change causing authentication requests to fail.
- A downstream dependency failure affecting multiple services.
For example, a service with a 99.9% SLO experiencing a 2% request failure rate has a burn rate of 20×. At a sustained 20× rate, an initially full 30-day error budget would be consumed in approximately 36 hours under constant traffic.
2% ÷ 0.1% = 20× → 30 days ÷ 20 = 1.5 days = 36 hoursFast burns need urgent investigation and mitigation, because the time available to protect the remaining budget may be short. If part of the budget is already used, it is shorter still.
What is a slow burn?
A slow burn occurs when a service consumes its error budget at a lower rate over an extended period. Examples include:
- Intermittent failures affecting a small percentage of users.
- A recurring timeout in a background workflow.
- Gradually increasing latency affecting a subset of requests.
- A minor application defect causing persistent transaction failures.
For example, a 99.9% SLO with a consistent 0.15% failure rate has a burn rate of 1.5×. The degradation may not look urgent at any particular moment. But if it persists, the service exhausts its error budget before the window ends.
0.15% ÷ 0.1% = 1.5× → 30 days ÷ 1.5 = 20 daysWhy are slow burns easy to miss?
A slow burn rarely crosses a static error-rate threshold. A 0.15% failure rate looks like noise on most dashboards, and no single hour looks like an incident.
Over a full window, though, a constant 1.5× uses 150% of the error budget. The SLO breaches on day 20, with no outage anyone would remember. Slow burns are why remaining budget and long-window burn rate both need watching, not only error spikes.
How do you detect fast and slow burns?
A monitoring strategy that only detects severe spikes misses persistent degradation. One that only looks at long-term trends responds too slowly to sudden failures. Effective SLO monitoring accounts for both.
The standard approach is multi-window, multi-burn-rate alerting: a high threshold over short windows to catch fast burns, and a low threshold over long windows to catch slow ones. Each rule checks a long and a short window together, so it fires only while the burn is still happening.
| Pattern | Burn rate | Long window | Short window | Budget used when it fires | Response |
|---|---|---|---|---|---|
| Fast burn | 14.4× | 1 hour | 5 minutes | 2% | Alert on-call now |
| Sustained burn | 6× | 6 hours | 30 minutes | 5% | Alert on-call |
| Slow burn | 1× | 3 days | 6 hours | 10% | Ticket |
For how these thresholds are calculated and a worked incident, read Multi-window burn-rate alerting.
Frequently asked questions about fast and slow burns
What is a fast burn in SRE?
A fast burn is rapid error-budget consumption over a short period, typically a burn rate of 10× or more. At 20×, a full 30-day error budget would be gone in about 36 hours.
What is a slow burn in SRE?
A slow burn is low but persistent error-budget consumption, typically a burn rate a little above 1×. At a constant 1.5×, a 30-day error budget is exhausted by day 20.
Which is more dangerous, a fast burn or a slow burn?
A fast burn is more urgent, because it can breach an SLO within hours. A slow burn is easier to miss, because it rarely looks like an incident. Both can breach the SLO, so both need alerts.
What burn rate counts as a fast burn?
There is no single cut-off. For a 99.9% SLO over 30 days, a common fast-burn alert fires at 14.4× over 1 hour, which means 2% of the budget used in that hour.
Should a slow burn alert on-call?
Usually not. Slow burns leave days to respond, so most teams open a ticket and fix the cause in planned work, keeping on-call alerts for fast and sustained burns.
Key takeaways
- A fast burn uses a large share of the budget in hours; a slow burn uses it over weeks.
- At 20×, a full 30-day budget lasts about 36 hours; at 1.5×, about 20 days.
- Slow burns rarely look like incidents, but can still breach the SLO.
- Multi-window, multi-burn-rate alerts catch both, with different thresholds and responses.