Context
An SLO burn-rate alert measures how quickly a service consumes its allowed bad-event budget. Combining long and short windows can identify sustained urgent failure while avoiding alerts based only on a stale incident. Derive thresholds from the objective and response policy instead of copying numbers without their assumptions.
Define valid and bad events first
Specify the user journey, valid-event denominator, bad-event condition, objective, and measurement period. Decide how timeouts, missing telemetry, retries, and client-caused errors are treated. A burn-rate formula cannot repair an ambiguous service-level indicator.
Keep numerator and denominator aligned by population and labels. Counting all server errors against only one route's requests produces a misleading ratio. Where a global SLO is intended, aggregate event counts before calculating the ratio rather than averaging percentages from unequally busy instances.
Calculate the rate against the allowed fraction
For an illustrative 99.9% event-based objective, the allowed bad fraction is 0.001. A measured bad fraction of 0.01 gives a burn rate of 10. If that rate persisted under comparable traffic assumptions, the budget would be consumed ten times as fast as the objective permits.
To relate a threshold to a fraction of budget consumed over a window, use the measurement-period duration consistently. In a 30-day period containing 720 hours, a burn rate of 14.4 sustained for one hour corresponds to 2% of the period's budget under the event-rate assumptions of the example.
State those assumptions. A request-based budget and a time-based budget are not interchangeable, and changing traffic volume can affect how an observed window relates to future consumption.
Combine a long and short window
Google's SRE Workbook describes multiwindow, multi-burn-rate alerting. A fast alert can require both a longer window and a shorter window to exceed the chosen burn threshold. The long window establishes significant consumption; the short window confirms the problem remains active.
For the illustrative 30-day objective, a common fast pair uses one hour and five minutes at 14.4 times burn. A slower pair can use six hours and thirty minutes at six times burn. These are starting examples to evaluate, not mandatory values for every service.
Route urgency according to response needs. A severe active burn may warrant paging, while slower consumption may create owned engineering work. Avoid using the same notification behavior for every threshold simply because the expressions look similar.
Handle low traffic and missing evidence
A single failure in a tiny request population can produce a large ratio. Decide how low-volume services obtain meaningful availability evidence, such as appropriate aggregation or complementary synthetic checks. Do not hide real user failures behind an arbitrary minimum without reviewing its consequence.
Missing telemetry should not silently become zero bad events. Alert on the measurement pipeline where needed and distinguish no traffic from no data. Test denominator behavior explicitly so an absent series does not disable the intended response unnoticed.
Quick diagnostic map
| Evidence | Question | Next check |
|---|---|---|
| Alert fires after recovery | Short-window condition missing | Combined window logic |
| Ratio varies with replica count | Aggregation mismatch | Sum event counts before division |
| One low-volume failure pages repeatedly | Signal policy unsuitable | Traffic model and complementary checks |
| Empty graph appears healthy | Missing data treated as success | Telemetry availability |
A focused operator exercise
Create test event series for a brief spike, sustained severe failure, slow degradation, recovery, low traffic, and missing telemetry. Calculate expected bad fractions and burn rates independently, then evaluate the actual alert rules against them.
Check activation, recovery, grouping, and notification routing. Verify the page explains the affected journey, objective, observed windows, and next diagnostic action. Keep the example period and threshold assumptions in the rule documentation so a later SLO change does not leave stale constants.
Review alerts against operational outcomes
After incidents, compare the alert timeline with customer impact and useful response time. Adjust the policy when evidence supports it. A burn alert should create an actionable decision about reliability, not merely display a mathematically impressive number.
Frequently asked questions
Does burn rate ten mean ten percent errors?
No. It is relative to the allowed bad fraction. For a 99.9% objective, ten times burn corresponds to a 1% bad fraction.
Should every SLO use the example thresholds?
No. Derive and test them against the objective, period, traffic model, and response requirements.
Continue the investigation
- Software SLOs: connect error-budget burn to release decisions
- Prometheus Alerts Flapping: Separate Rule State, Missing Data, and Notification Timing
Browse the cloud, server and infrastructure guide library for related operational questions.
Explore Clouvenix Service Reliability, SLA & SLO to discuss implementation, validation and operational handover.