A burn rate measures how fast you are using up your error budget compared with the pace your SLO allows. A burn rate of 1 spends the budget exactly by the end of the window. Alerting on burn rate pages you in proportion to the damage, instead of on every blip.
Error budget in one paragraph
If your SLO says 99.9 percent of requests succeed over 30 days, you are allowed 0.1 percent failures. That allowance is the error budget. The question for alerting is how quickly you are consuming it.
The SRE workbook defines it plainly: burn rate is how fast, relative to the SLO, the service consumes the error budget.
Reading a burn rate
Take the 99.9 percent SLO over 30 days. A burn rate of 1 means the error rate is 0.1 percent and the budget lasts exactly the 30 days. A burn rate of 10 means the budget would be gone in about three days. The workbook's table says a burn rate of 14.4 sustained for one hour consumes 2 percent of the budget, which is why it works as a fast paging threshold.
The multiwindow pattern
Pair a long window with a short one and fire only when both exceed the threshold. The long window shows that a meaningful amount of budget is being spent. The short window, about a twelfth of the long one, shows the problem is still happening, so the alert clears soon after recovery.
The workbook suggests these starting points for a 99.9 percent SLO:
- Page: 1 hour long window, 5 minute short window, burn rate 14.4, which is 2 percent of budget
- Page: 6 hour long window, 30 minute short window, burn rate 6, which is 5 percent of budget
- Ticket: 3 day long window, 6 hour short window, burn rate 1, which is 10 percent of budget
Fast burns page someone. Slow burns create a ticket for working hours.
Why not a simple threshold
The workbook walks through the weak options. An error rate over the SLO for a short window detects quickly but fires on tiny events, because a 0.1 percent error rate over 10 minutes uses only about 0.02 percent of a month's budget. A longer window is more precise but keeps firing for hours after recovery. A duration clause treats a total outage and a small leak the same.
What you need to try it
- a clear definition of a good request and a bad one
- an error ratio metric you trust
- an SLO your team has agreed on, even if it is rough
Start with one service, run the alerts without paging for two weeks, and compare them with the incidents you remember.
Quick check
Do I need a 99.9 percent SLO to use this?
No. The method works for any target. The thresholds in the table are starting values for 99.9 percent, so recompute them for yours.
Is this only for latency?
It works for any ratio of good events to total events, including latency under a threshold.
Sources
Last reviewed: 19 October 2026.
