# Fast burn vs slow burn: how error budgets run out

Source: https://steadynines.com/learn/fast-burn-vs-slow-burn
Author: Balavigneshwaran M, SteadyNines
Last updated: 2026-11-10

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.

**Short answer:** A **fast burn** is rapid error-budget consumption, such as a 20× burn rate after a faulty deployment, which would empty a full 30-day budget in about 36 hours. A **slow burn** is low but persistent consumption, such as a steady 1.5× from an intermittent defect, which exhausts the budget by day 20. Fast burns need an on-call alert now; slow burns need a ticket.

## 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](https://steadynines.com/learn/burn-rate): how fast the budget is being used compared with the pace the SLO allows.

> Figure: One 30-day error budget at three paces: a 1× reference line uses it exactly by day 30; a slow burn at 1.5× exhausts it on day 20; a fast burn at 20× starting on day 10 empties the remaining 83% in about 30 hours.

|  | 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 |

Example alerts are common starting thresholds for a 99.9% SLO over 30 days.

## 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.

**Fast burn:** `2% ÷ 0.1% = 20× → 30 days ÷ 20 = 1.5 days = 36 hours`

Fast 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.

**Slow burn:** `0.15% ÷ 0.1% = 1.5× → 30 days ÷ 1.5 = 20 days`

## Why 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 |

Common starting thresholds for a 99.9% SLO over 30 days.

For how these thresholds are calculated and a worked incident, read [Multi-window burn-rate alerting](https://steadynines.com/learn/multi-window-burn-rate-alerts).

## 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.

[How SteadyNines acts on burn rate](https://steadynines.com/product/how-it-works)