What a burn rate is
A burn rate is how fast a service uses its error budget, relative to its SLO. At 1x, the budget runs out exactly at the end of the window. With a 99.9% SLO over 30 days, a steady 0.1% error rate uses all of it, the same budget as 43m 12s of full downtime. At 2x it is gone in 15 days, and at 10x in 3 days. These rates come from the chapter on alerting in Google's SRE Workbook. To get a burn rate, divide the error rate by what the SLO allows: 1% ÷ 0.1% is 10x.
Where 14.4, 6 and 1 come from
A burn rate alert starts from how much of the budget you accept losing before someone acts: threshold = SLO window hours × share of budget ÷ long window hours. A 30-day window is 720 hours, so 2% over 1 hour is 720 × 2% ÷ 1 = 14.4. 5% over 6 hours gives 6, and 10% over 3 days gives 1. These are the Workbook's recommended starting points for a 99.9% SLO: page on the first two, open a ticket on the third. The SLO then sets the error rate to alert on. 14.4 × 0.1% is 1.44% errors, and at 99.99% the same burn rate is 0.144%.
A long window shows a real problem rather than a blip, but alone it keeps the alert firing after the errors stop: for about an hour with a 1-hour window. So the Workbook adds a short window, and the alert fires only while both are above the threshold. In its example, the alert stops 5 minutes after the errors do. Its guideline is a short window 1/12 as long: 5 minutes with 1 hour, 30 minutes with 6 hours, and 6 hours with 3 days.
Pitfall: the window sets the numbers
14.4x spends exactly 2% of the budget in an hour only over a 720-hour window. The same shares over 28 days give 13.44, 5.6 and 0.93. That is our own calculation, not a published table. At 0.93x the budget outlasts the window, so that ticket can fire while the SLO is still on course.
Vendors choose other tiers. Datadog suggests 10%, 20% and 40% over 1, 6 and 24 hours for a 7-day target, which gives 16.8, 5.6 and 2.8. For a 90-day target it suggests 1%, 3% and 5%, which gives 21.6, 10.8 and 4.5. Set the window and type those into the rows to reproduce them. Google Cloud suggests starting with 10x over 1 or 2 hours, and 2x over 24 hours. Check their docs for current values.
Below the table, copy these alerts as a Prometheus rule file in the Workbook's form, or as Datadog monitors for Terraform. Datadog takes only 7, 30 or 90-day SLOs and long windows of 1 to 48 hours, so its copy leaves out a 3-day tier.
Pitfall: an alert that can't fire
The largest possible burn rate is 1 ÷ the error rate the SLO allows, reached when every request fails. At 99.9% that is 1,000x, and at 96% it is 25x, Datadog's example. Below an SLO of about 93.06% it is under 14.4, so a 14.4x alert can never fire. The Workbook makes the same point for a 90% target: a full outage uses only 1.4% of the budget in an hour, short of the 2% the alert waits for. The calculator marks such a row "Can't fire". Use a smaller share of budget or lengthen the long window.
FAQ
What is an SLO burn rate?
It measures how quickly a service spends its error budget, compared with the pace that would use it up exactly at the end of the SLO window. At 2x the budget is gone in half the window, and at 10x in a tenth, so over 30 days that is 15 days and 3 days.
What does a burn rate of 14.4 mean?
The service is using its budget 14.4 times faster than the rate that would use it up exactly at the end of the window. Over a 30-day window (720 hours), that is 2% of the budget an hour, and all of it in 2 days 2 hours. At a 99.9% SLO, it is a 1.44% error rate.
How do you calculate burn rate?
Divide the error rate by the error rate the SLO allows, which is 100% minus the SLO. 1% errors at a 99.9% SLO is 1% ÷ 0.1% = 10x. To work out an alert threshold instead, use SLO window hours × share of budget ÷ alert window hours: 720 × 2% ÷ 1 = 14.4.
What should an SLO burn rate alert be set to?
Google's SRE Workbook recommends starting, for a 99.9% SLO over 30 days, with a page at 14.4x over 1 hour and at 6x over 6 hours, and a ticket at 1x over 3 days. Those thresholds spend 2%, 5% and 10% of the budget. Google Cloud suggests starting with 10x over 1 or 2 hours for a fast burn, and 2x over 24 hours for a slow one.
Do the 14.4, 6 and 1 burn rates work for a 7-day or 28-day window?
The method does, but the numbers change, because 14.4 assumes a 720-hour window. By our own calculation, 2% over 1 hour, 5% over 6 hours and 10% over 3 days give 13.44, 5.6 and 0.93 over 28 days, and 3.36, 1.4 and 0.23 over 7 days. For a 7-day target, Datadog uses 10%, 20% and 40% over 1, 6 and 24 hours, which gives 16.8, 5.6 and 2.8.
Do burn rate alerts work for low-traffic services?
They can page on a single failure, because one failure moves the error rate a long way. Google's SRE Workbook gives a service with 10 requests an hour: one failed request is a 10% hourly error rate, which uses 13.9% of a 30-day budget at 99.9%, so it would page. 10% ÷ 0.1% is a burn rate of 100x. The Workbook's options are to generate artificial traffic, combine small services for monitoring, change the product so one failure matters less, or lower the SLO or use a longer alert window.