Guides 6 min read
Error Budgets: What They Are and How to Use One
How to calculate an error budget from an SLO, what spends it, how burn rate works, and how to write an error budget policy your team will actually follow.
ReadGlossary · Reliability metrics
What is burn rate?
Burn rate is how fast a service is spending its error budget, relative to what its SLO allows. At a burn rate of 1 the budget lasts exactly the whole window; at 2 it is gone halfway through.
How it works and why it matters
Burn rate compares the error rate you see now with the rate the SLO allows. With a 99.9% SLO the allowed error rate is 0.1%, so 0.5% of requests failing is a burn rate of 5, and at that pace a 30-day error budget lasts 6 days.
Google’s SRE workbook bases alerts on it. For a 99.9% SLO over 30 days, it suggests paging when 2% of the budget burns within an hour (a burn rate of 14.4) or 5% within six hours (a burn rate of 6), and opening a ticket when 10% burns within three days (a burn rate of 1). Each alert also checks a short window, so it stops soon after the problem does.
A full outage burns fast, and a plain “site is down” alert catches it just as quickly: against 99.9%, every minute down is a burn rate of 1,000. Burn rate alerts earn their keep on partial failures, such as 2% of requests failing for hours, which never takes the site down but empties the month’s budget.
Formula
Burn rate = observed error rate ÷ (100% − SLO); time until the budget is gone = window ÷ burn rate
Example: Against a 99.9% SLO, a full outage burns at 1,000, so 20 minutes of it spends 46% of a 30-day budget of 43 minutes and 12 seconds. 0.5% of checks failing burns at 5 and empties the budget in 6 days.
How Uptimecheck helps
Uptimecheck doesn’t calculate a burn rate. For availability, its alerts cover the fast end: with a 1-minute interval, an outage confirmed by a second check reaches you within a minute or two. Slow alerts, sent after three slow checks in a row, catch a service that is up but too slow, and reports for the last 7, 30 or 90 days show how much of a budget is already spent.
14-day free trial · No credit card required
Read more in the guides
Guides 7 min read
How to Reduce False Alerts in Uptime Monitoring
False alerts teach teams to ignore monitoring. How to cut the noise: confirm every failure with a second check, set sensible timeouts, validate the right URL and route alerts to the people who can act.
ReadQuestions
What is a good burn rate alert threshold?
A common start for a 99.9% SLO over 30 days is to page at a burn rate of 14.4 over one hour or 6 over six hours, and to open a ticket at 1 over three days. Adjust after a few months of real alerts.
Why does a burn rate alert use two windows?
The long window makes sure enough budget has burned to matter. The short window makes sure it is still burning, so the alert stops soon after the problem is fixed.
Is a burn rate of 1 bad?
No. It spends the budget exactly by the end of the window, which is what the SLO allows. Above 1 the budget runs out early; below 1 some is left.
More from Reliability metrics
All terms-
Uptime
The time a service is available and working, usually as a percentage of a period. Read the definition : Uptime -
Downtime
The time a service is unavailable or too broken to use. Read the definition : Downtime -
The nines (99.9% uptime)
Nines of availability Availability targets counted in nines, from 99% to 99.999%, and the downtime each allows. Read the definition : The nines (99.9% uptime)
Downtime is obsolete.
Set up your first monitor in under a minute, or look around the live demo first.
14-day free trial · No credit card required