{{ summaryTitle }} {{ summaryValue }} {{ summaryLine }} {{ badge.label }} {{ badge.value }}
SLO burn and alert policy inputs
Name the service, endpoint group, or SLO slice being reviewed.
A 99.9% SLO leaves a 0.1% sustainable failure rate.
%
The window converts burn rate into full-budget consumption per hour.
days
Keep its numerator, denominator, and traffic slice aligned with the SLO.
%
Use the remaining-budget percentage from the same SLO window.
%
Match the lookback in the monitoring query or incident snapshot.
hr
Use the threshold from the service's actual alert policy.
x
Keep this at or below the fast page threshold.
x
The default four-tier policy uses 3x over its 24-hour row.
x
Keep the four thresholds in descending order.
x
{{ workflowFeedback }}
Use a documented operating reserve; it cannot exceed budget remaining.
percentage points
{{ tableExportStatus }}
MeasureValueOperational meaningCopy
{{ row.label }}{{ row.value }}{{ row.note }}
{{ tableExportStatus }}
Policy rowThresholdError-ratio triggerCurrent decisionCopy
{{ row.label }}{{ formatBurn(row.threshold_burn) }}{{ formatPercent(row.trigger_error_ratio_pct, 3) }}{{ row.decision }}
{{ chartExportStatus }}
{{ summaryAnnouncement }}

When a service starts failing, the raw error percentage does not say how urgently the reliability target is threatened. A 0.5% error ratio is severe for a 99.99% service-level objective (SLO), but much less alarming for a 99% objective. Error-budget burn rate puts both cases on the same scale by comparing the observed error ratio with the failure allowance implied by the SLO.

Service-level indicator (SLI)
The measured good-event or bad-event ratio for the eligible traffic covered by the objective.
Service-level objective (SLO)
The target success percentage over a defined window, such as 99.9% over 30 days.
Error budget
The failure allowance left by the objective. A 99.9% SLO allows 0.1% bad events over its window.
Burn rate
The observed bad-event ratio divided by that allowance.

A burn rate of 1x spends budget at exactly the pace that would use a fresh budget by the end of its policy window. At 2x, a full budget lasts half a window. At 10x, it lasts one tenth. That common scale helps an on-call team distinguish a sharp page-worthy incident from a slower reliability leak that can be handled through a ticket.

Alert policy needs both pace and duration. A high burn measured over a short lookback detects major incidents quickly, while a lower threshold over a longer lookback catches sustained damage without paging on every brief spike. The familiar 14.4x one-hour and 6x six-hour examples represent different combinations of response urgency and budget spend; they are starting points, not universal policy.

Remaining budget adds a separate operational question. Two services can have the same burn rate while one has weeks of allowance left and the other has almost none. Straight-line runway converts the current pace and remaining budget into an exhaustion estimate, but it assumes the sampled error ratio continues unchanged.

The most consequential mistake is comparing unlike measurements. The error numerator, eligible-event denominator, traffic slice, SLO window, and budget balance must all refer to the same objective. A precise multiplier built from mismatched dashboards is not a reliable incident signal.

How to Use This Tool:

Begin with the policy definition, then add a current error sample from the same SLI and traffic scope.

  1. Enter a short Service or SLO name, the Availability SLO, and its full SLO window.
  2. Enter the Current error ratio and its Observed window, then set Budget remaining from the current SLO period. Use Runway reserve only when part of that balance should be withheld.
  3. Keep the four alert thresholds in descending order from Fast page threshold through Slow ticket threshold. Replace the defaults with the service's actual alert policy when it differs.
  4. Read Burn snapshot for pace, Alert policy for crossed thresholds, and Budget runway for the straight-line exhaustion estimate. Correct any input warning before relying on those results.

Interpreting Results:

Current burn rate is the normalized pace. Below 1x, the sampled error ratio is below the full-window allowance pace. Exactly 1x would consume a fresh budget over one complete SLO window. Above 1x, a fresh budget would be exhausted early if the same ratio persisted.

  • Usable budget remaining subtracts the chosen reserve from the reported remaining budget.
  • Runway to exhaustion is conditional on a constant current error ratio; it is not a forecast of recovery or future traffic.
  • An alert row is crossed when current burn is greater than or equal to its threshold. Confirm the monitoring query uses the same lookback before routing a page or ticket.
  • At zero current errors, runway has no finite exhaustion time. That does not prove the service will remain without errors.

Technical Details:

Burn rate normalizes a measured error ratio against the exact error allowance of an SLO. The policy window then converts that dimensionless multiple into budget spend per hour and a remaining-budget runway.

Formula Core:

Let S be the SLO percentage, r the observed error percentage, and W the SLO window in hours. The error allowance E and burn rate B are:

E=100S B=rE

If M is the reported budget remaining and R is the held reserve, both in percentage points of the original budget, usable budget is U = M − R. Budget consumption rate c and runway T are:

c=B×100W T=Uc

For a 99.9% SLO, the allowance is 0.1%. An observed 0.8% error ratio gives 8x burn. Over 30 days, W is 720 hours, so the service consumes about 1.111% of a full error budget per hour. With 62% usable budget left, straight-line runway is 55.8 hours. Calculations retain full numeric precision; displayed values are rounded for readability.

Rule Core:

Alert classification uses the first crossed threshold in descending urgency. Equality belongs to the crossed state.

Default error budget burn alert thresholds and lookbacks
StateThresholdLookbackRoute
Fast page14.4x1 hourPage
Sustained page6x6 hoursPage
Ticket3x24 hoursTicket
Watch1x72 hoursTicket
SteadyBelow 1xNo default route

For threshold Q and lookback L, the triggering error ratio is Q × E. The share of a full budget represented by that row is Q × L × 100 ÷ W. These rows describe the entered policy; they do not require the short-window and long-window conditions of a production multi-window alert to be true simultaneously.

Accuracy Notes:

The arithmetic is deterministic, but its usefulness depends on the measurement supplied.

  • Low-traffic services can show extreme burn from one or two failures; inspect event counts as well as ratios.
  • A short incident sample may end before the straight-line runway is reached, or worsen after the sample.
  • Maintenance exclusions, delayed telemetry, partial traffic slices, and inconsistent eligibility rules can make the budget balance and error ratio incomparable.
  • Burn rate shows that the SLO is threatened, not why. Use service telemetry and incident diagnostics for root cause.

Worked Examples:

Sustained pressure on a checkout SLO

A 99.9% SLO over 30 days with a 0.8% current error ratio produces 8x burn. With 62% usable budget remaining, runway is 55.8 hours. The 6x sustained-page, 3x ticket, and 1x watch rows are crossed, while the 14.4x fast-page row is not. The correct response still depends on whether each monitoring lookback confirms the same sustained condition.

A quiet low-traffic service

With a current error ratio of 0%, burn and hourly budget spend are both zero, so no finite exhaustion time is reported. That result describes the sample only. A single later failure can move the ratio sharply when request volume is small.

References: