Burn Rate

Burn rate compares the observed failure fraction with the failure fraction allowed by an SLO. For a ratio-based indicator with target s, it is an observed error ratio divided by (1 − s). The SRE workbook uses this normalized measure to design alerts for consequential budget consumption.

An error percentage has different significance under different objectives. Burn rate makes that relationship explicit: a rate of 1 matches the permitted fraction, while a higher rate exceeds it. Converting the ratio to a depletion time additionally requires a remaining budget and an expected traffic rate; it is not a clock on its own.

The arithmetic, including where 14.4 comes from

Define which eligible events count as good and which count as failures. The workbook recommends a good/eligible event ratio for this calculation; its failure allowance is 1 minus the target. A latency value in milliseconds needs a good-event threshold before this ratio arithmetic applies.

For a 99.9% objective over 30 days, the permitted error fraction is 0.1%. Observing 0.1% therefore gives burn rate 1. The following table converts higher ratios into depletion times under its stated traffic and starting-budget assumptions.

Burn rate	Error rate against a 99.9% objective	Time to exhaust a full 30-day budget, at that error rate and the month’s average request rate
1	0.1%	30 days
2	0.2%	15 days
10	1%	3 days
1,000	100%	43 minutes

That last row is the one that reframes an outage. A total failure against a 99.9% monthly objective does not give you a day to respond; it gives you the better part of an hour before the month’s allowance is gone.

Every condition in that column heading matters, because the right-hand column is arithmetic on a ratio rather than a reading of the clock: it assumes the budget is untouched, the error rate holds, and requests keep arriving at the month’s average pace. The budget of a request-based objective is a count of requests, so a given burn rate spends a different amount of it per hour depending on traffic: against a million-request month with a thousand failures allowed, one failure in a hundred requests and a hundred failures in ten thousand are both a burn rate of 10, but the first hour has spent 0.1% of the budget and the second 10%. And the table starts from a full budget; two-thirds of the way into a month’s allowance, every row’s time is a third of what it says. Use the rate to decide whether the current burn warrants a response, and the remaining budget together with expected traffic to say how long is actually left.

To choose a threshold, express a tolerable budget fraction over an observation window. At the period’s average request pace, the burn threshold is that fraction divided by the window’s fraction of the SLO period. One hour is 1/720 of 30 days, so 2% / (1/720) = 14.4. Similarly, 5% over six hours gives 6, and 10% over three days gives 1. The workbook proposes these as starting points, to be adjusted for the service and baseline page load. Uneven traffic changes the actual monthly budget share consumed within each window.

Why the configuration needs more than one rate

A rule tuned only for rapid exhaustion can miss a sustained lower burn. The workbook illustrates a 36× threshold that never catches a constant 35× rate, although at the assumed traffic pace it exhausts a full 30-day allowance in about 20.5 hours. Several windows and thresholds cover different incident durations.

So a working configuration pairs a fast rule with a slow one, and sends them to different places. The recommended starting set for a 99.9% objective:

Severity	Long window	Short window	Burn rate	Budget consumed
Page	1 hour	5 minutes	14.4	2%
Page	6 hours	30 minutes	6	5%
Ticket	3 days	6 hours	1	10%

Each row requires its long and short windows to exceed the threshold. The short window reduces lingering alerts after recovery, but its duration still bounds how quickly old errors disappear. The workbook’s starting ratio is one-twelfth of the long window. For the six-hour ticket window, a sustained 5× rate followed by zero errors at steady traffic takes 4.8 hours to reach 1×; the table does not promise minute-scale recovery for every row.

The ticket row targets a sustained lower rate of consumption, leaving more response time under the stated budget and traffic assumptions. With a strict greater-than comparison, a value exactly at 1× does not fire. An almost exhausted budget can still require attention below the burn thresholds, so monitor the remaining allowance separately from these rules.

The workbook compares rules by precision, recall, detection delay, and reset delay: how many notifications correspond to significant incidents, how many significant incidents are caught, how quickly they are detected, and how long alerts remain after recovery. Choose thresholds by those consequences rather than optimizing notification count alone.

Where the number stops meaning anything

Interpret the ratio alongside event counts, notification behavior, and the budget definition. These considerations affect different parts of the design.

• Low event counts. At ten requests per hour, one failure gives 10% hourly errors and 100× burn against a 99.9% SLO. At that steady pace, one of the monthly 7.2 permitted failures uses 13.9% of the allowance. The workbook prints 1,000× for this example, but 10% / 0.1% is 100×. Small counts make ratios sensitive to individual requests. Whether to page or revise the objective depends on failure impact and available recovery, not on a claim that seven failures per month is inherently indefensible.
• Overlapping notifications. A rapid incident can cross several window thresholds. Define grouping and inhibition so one incident does not generate unnecessary page and ticket duplicates, and test that notifications resume after suppression ends.
• The budget window resetting. A rolling window and a calendar window behave differently at the boundary, and a calendar one hands you a fresh budget on the first of the month regardless of what the service did on the last day of the previous one. Neither is wrong, but a team reading a burn rate without knowing which it is will misjudge how much room it has. State the window alongside the number.
• Expensive window calculations. Long-range queries process more samples. Recording rules can precompute results for repeated use, at their own evaluation and storage cost. Counters for eligible and failed events support rate calculations; handle resets, missing series, and compatible aggregation consistently.

Thresholds and windows add configuration that must be understood, tested, and maintained. Record the event definition, traffic assumptions, routing, and response expected from each rule. Burn rate makes the relationship to the SLO explicit; it does not choose the business consequences or response policy.

Burn rate presupposes the thing it spends. If a service has no agreed objective, computing one produces a number with no denominator; see error budget for what is being consumed and SLO for the target it comes from. The surrounding practice — what to measure, what to page on, and what to keep for diagnosis — is worked through in Only a Few Times a Day.

References

• Google SRE Workbook — Alerting on SLOs
• Google SRE Workbook — Implementing SLOs
• Google SRE Workbook — Monitoring

The recommended parameters are starting points the source says depend on the service.