Burn-rate alerts

Paging when a 30-day SLO dips below target is too late. By then the month is already ruined. A burn rate asks a faster question: at the current error rate, how quickly are we spending the budget? A burn rate of 1 means the budget runs out exactly at the end of the window.

Walking through the arithmetic

For a 99.9% SLO, the sustainable error ratio is 0.1%.

Burn rate = current error ratio / allowed error ratio

Error ratio 1%:  1% / 0.1% = 10x
Budget gone in:  30 days / 10 = 3 days

Now pick a threshold. Say you want to page when you would burn 2% of the 30-day budget in one hour.

30 days = 720 hours
2% of budget in 1 of 720 hours -> burn rate = 0.02 / (1 / 720) = 14.4
Error ratio at 14.4x = 14.4 x 0.001 = 1.44%

The 14.4x pattern

Google's SRE Workbook recommends multi-window alerts. Page only when both windows agree:

• Burn rate over 1 hour is above 14.4, and
• Burn rate over 5 minutes is above 14.4.

The long window gives precision, so a brief spike does not page anyone. The short window confirms the burn is still happening, and it clears the alert quickly after recovery. A slower companion alert, such as 6x over 6 hours and 30 minutes, catches bleeds that the fast alert misses.

This sketch uses placeholder metric names. Copy the exact tables from the workbook rather than inventing constants. The query below is the 1-hour burn rate against a 99.9% SLO, where the error budget is 0.001.

(
  sum(rate(http_requests_bad[1h])) / sum(rate(http_requests_total[1h]))
) / 0.001 > 14.4

Repeat the same expression with [5m], and combine the two with and.

Exhaustion table

Keep this near your runbook. It shows how fast a sustained error rate empties a 99.9% monthly budget.

A total outage should also trigger a separate "service dark" alert. Burn-rate tiers catch partial degradations that an up-or-down check misses. During an incident, quote the burn rate in the channel, such as "burning about 20x on the 1-hour window." It tells leadership how urgent the problem is.

Common mistakes

• Alerting only on the monthly SLO breach. You learn about it after the budget is gone.
• Using one error-rate threshold for everything. It does not account for the budget left.
• Defining "error" differently in the alert and the SLO. Use one definition for both.

Check yourself

1. What is the burn rate of a 1% error rate on a 99.9% SLO? Answer: 10, because 1% divided by 0.1% is 10.
2. Why check both the 1-hour and 5-minute windows? Answer: the 1-hour window avoids paging on brief spikes. The 5-minute window confirms the burn is ongoing and clears the alert quickly after recovery.

Key takeaways

• Burn rate equals the current error ratio divided by the allowed ratio.
• For 99.9% over 30 days, page on 14.4x over both 1 hour and 5 minutes.
• Threshold alerts alone ignore the budget, so pair them with burn rates.
• Next, latency SLOs show how to measure "fast enough."

Further learning

The SRE Workbook's chapter on alerting on SLOs has the full tables. Copy them rather than rebuilding the constants.