Burn Rate

What burn rate means

Every SLO implies an error budget. An availability objective of 99.9% over 30 days allows 0.1% of requests to fail, which is the budget. Burn rate tells you how quickly that budget is being spent right now. It is defined as:

burn rate = observed error ratio / (1 - SLO target)

With a 99.9% SLO the allowed error ratio is 0.001. If 0.5% of requests currently fail, the burn rate is 0.005 / 0.001 = 5. At that pace the entire 30-day budget would be gone after 30 / 5 = 6 days. A burn rate of exactly 1 means you are on track to end the window with zero budget left, and anything below 1 leaves budget to spare.

The concept is useful because it normalizes errors against the objective. A 0.5% error rate is a crisis for a 99.99% service and harmless for a 99% one; burn rate expresses both cases in the same unit.

The math behind burn-rate alerts

The share of budget consumed during an alert window follows directly from the burn rate:

budget consumed = burn rate x alert window / SLO period

For a 30-day period (720 hours), a burn rate of 14.4 sustained for one hour consumes 14.4 x 1 / 720 = 2% of the budget. A burn rate of 6 over six hours consumes 6 x 6 / 720 = 5%. A burn rate of 1 over three days (72 hours) consumes 10%. The time until the budget is exhausted is simply the SLO period divided by the burn rate, so a constant 14.4x burn empties a 30-day budget in about 50 hours.

Working backwards is how alert thresholds are chosen: decide which share of the budget you are willing to lose before someone is paged, pick a window, and compute the burn rate.

Multiwindow, multi-burn-rate alerts

The Google SRE Workbook (chapter "Alerting on SLOs") recommends combining several burn rates with two windows each. Starting values for a 99.9% SLO over 30 days are:

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

An alert fires only if the burn rate exceeds the threshold in both the long and the short window. The long window ensures enough budget has really been spent to justify waking someone up. The short window, about one twelfth of the long one, makes the alert stop shortly after the problem is fixed, instead of firing for another hour while the long window still contains old errors. Fast burns are caught within minutes, slow burns within hours, and minor blips that would never threaten the SLO stay silent, which directly reduces alert fatigue.

Detection speed scales with severity. During a complete outage with 100% errors and constant traffic, the one-hour error ratio crosses the 14.4x threshold of 1.44% after roughly 52 seconds, so the page goes out in about a minute. A smaller incident with 2% errors (burn rate 20) needs about 43 minutes to trip the same rule, which is acceptable because it is consuming budget far more slowly.

Example: PromQL rule

An illustrative Prometheus alert for the fastest tier, using request counters for a checkout service:

(
  sum(rate(http_requests_total{job="checkout",code=~"5.."}[1h]))
  / sum(rate(http_requests_total{job="checkout"}[1h]))
) > (14.4 * 0.001)
and
(
  sum(rate(http_requests_total{job="checkout",code=~"5.."}[5m]))
  / sum(rate(http_requests_total{job="checkout"}[5m]))
) > (14.4 * 0.001)

In practice teams precompute the ratios as recording rules for each window so that the alert expressions stay cheap and readable.

Best practices

• Alert on burn rate, not raw error counts. It ties paging directly to user impact as defined by the SLO.
• Use the workbook values as a starting point, then tune them based on how often alerts led to real action.
• Handle low traffic deliberately. When a service receives only a few requests per minute, a single failure can produce a huge burn rate. Add synthetic traffic, require a minimum request count, or group small services under a shared SLO.
• Apply it to latency SLOs too. Count requests slower than the threshold as "bad events"; the same formula works.
• Route by urgency. Fast burns go to on-call, slow burns become tickets.

Common mistakes

Using only a single short window produces flapping alerts on every brief spike. Using only a long window detects problems late and keeps alerting long after recovery. Another frequent error is computing the burn rate from averaged per-instance error rates instead of from summed good and total events, which gives small instances the same weight as large ones.

How Obseria helps

Obseria lets you define SLOs on any metric or span query and alert on them with multiwindow, multi-burn-rate rules out of the box, with the remaining error budget always visible. Alerts flow into incident management with the affected services and recent deployments attached.