{{ summaryTitle }}
{{ summaryPrimary }}
{{ summaryLine }}
{{ badge.label }}
Name the service, endpoint group, or SLO slice being evaluated.
Enter the target success percentage for the SLO.
%
Use the same window your dashboard uses to calculate remaining budget.
days
Enter the current bad-event percentage from metrics or a quick sample.
%
Set how much of the original error budget is still available.
%
Use the same lookback as the metric query or incident snapshot.
hr
Tune the short-window paging threshold.
x
Set the sustained page threshold used by the alert table and ladder.
x
Set the ticket threshold used by mitigation targets.
x
Keep this at 1x when you want any unsustainable long-window burn to create follow-up.
x
Metric Value Operational note Copy
{{ row.metric }} {{ row.value }} {{ row.note }}
Objective Burn target Error ratio ceiling Required reduction Next move Copy
{{ row.objective }} {{ row.burnTarget }} {{ row.errorCeiling }} {{ row.reduction }} {{ row.nextMove }}
Alert window Threshold Error ratio trigger Current status Budget spend at threshold Copy
{{ row.window }} {{ row.threshold }} {{ row.errorTrigger }} {{ row.currentStatus }} {{ row.budgetSpend }}
Tags: Devops, Diagnostics
Export to PDF Fullscreen
Customize
Advanced
:

Error budget burn rate measures how quickly a service is spending the failure allowance behind a service-level objective, or SLO. A 99.9% availability SLO leaves a 0.1% error budget. If the current bad-event ratio is 0.8%, the service is burning that allowance at 8.00x the steady pace.

That multiplier matters during incidents because a plain error percentage does not say how much time is left. A one-hour spike may be tolerable when most of the budget remains, or urgent when the same service already spent a large share of the period allowance. Burn rate connects the observed error ratio, the SLO target, and the remaining budget runway into one operational readout.

Burn-rate alerting also helps separate paging pressure from follow-up work. Very high burn over short windows can justify a page because the SLO may be lost quickly. Lower but sustained burn can still deserve a ticket because it will consume the budget if nobody changes the error rate. The exact thresholds should match the service, traffic pattern, and on-call policy.

Diagram comparing SLO error allowance, observed error ratio, burn multiple, and budget runway

A burn-rate reading is still a projection, not a root-cause analysis. It assumes the current error ratio continues, and it depends on the SLO definition being right for the service. Use it to size urgency and next actions, then check logs, recent deployments, user impact, regional spread, and monitoring windows before making a release or escalation decision.

Technical Details:

Error budget math starts with the SLO allowance. For an availability SLO, the allowed error percentage is 100 - SLO percent. Burn rate is the observed bad-event percentage divided by that allowance. A value of 1.00x means the service is consuming the budget at exactly the rate a full SLO window can sustain.

Runway adds the current remaining budget. A service can have the same burn multiple on two different days, but the operational urgency changes if one run has 90% budget remaining and another has 8% remaining. The runway estimate uses the current burn multiple and the SLO window length to calculate how many hours remain before the budget reaches zero.

Formula Core

The equations below use percent values because the inputs and outputs are displayed in percent units. The same ratios can be expressed as decimals if each percentage is divided by 100 consistently.

Error budget percent = 100-SLO percent Burn rate = current error ratio percenterror budget percent Budget consumed per hour = burn rate×100SLO window days×24 Runway to exhaustion = budget remaining percentbudget consumed per hour Observed-window spend = burn rate×observed hours×100SLO window days×24

With a 99.9% SLO, the error budget is 0.1%. A current error ratio of 0.8% gives 0.8 / 0.1 = 8.00x. Over a 30-day window, 8.00x consumes about 1.111% of the full budget every hour. If 62% of the original budget remains, the projected runway is about 55.8 hours, which the result formats as 2.3 days.

Input Accepted range Effect on the calculation
Service or SLO name Any text label Appears in the ledger, summary, and export payloads so incident notes use a consistent name.
Availability SLO Greater than 0% and less than 100% Sets the error budget percent. Higher SLOs leave smaller budgets and therefore higher burn multiples for the same error ratio.
SLO window Greater than 0 days Sets the compliance period used for runway, full-budget exhaustion, and alert-window budget spend.
Current error ratio 0% to 100% Represents observed bad events divided by eligible events for the measurement window.
Budget remaining 0% to 100% Sets how much of the original error budget remains for the runway projection.
Observed window Greater than 0 hours Calculates how much of the full budget the current sample spends over its own lookback window.

The alert rows compare the current burn rate with configurable thresholds. Their default values follow common SRE reference points for fast pages, sustained pages, tickets, and slow tickets. The error ratio trigger for each row is the threshold burn multiplied by the SLO error budget percent.

Alert row Default burn Window label Budget spend at threshold for 30 days Summary behavior
Fast page 14.40x 5 min / 1 hr 2% of the full budget in 1 hour Current burn greater than or equal to this threshold shows fast page pressure.
Sustained page 6.00x 30 min / 6 hr 5% of the full budget in 6 hours Current burn greater than or equal to this threshold shows sustained page pressure.
Ticket 3.00x 2 hr / 24 hr 10% of the full budget in 24 hours Current burn greater than or equal to this threshold shows ticket pressure.
Slow ticket 1.00x 6 hr / 72 hr 10% of the full budget in 72 hours Current burn at or above this threshold enters watch status when higher thresholds are not crossed.

The model is deterministic. It does not inspect a live SLO object, count raw requests, or decide which events should spend budget. The reader supplies the current bad-event ratio and remaining-budget value, so the result is only as reliable as those source metrics and the SLO definition behind them.

Everyday Use & Decision Guide:

Start with the SLO name and the same window used by the dashboard or review process. A 30-day service target should not be compared with a one-week budget unless the team is intentionally testing a different policy. Use Budget remaining from the SLO system when available; use 100% only when the window has just started or when you are modeling a fresh budget.

Set Current error ratio from the same lookback that produced the incident signal. If the metric query is a one-hour average, keep Observed window at 1 hour. If the query is a six-hour average, change the observed window too, because Observed-window budget spend depends on that duration.

  • Burn Ledger is the first place to verify Current burn rate, Budget consumed per hour, Runway to exhaustion, Fresh full-budget runway, and Error ratio at 1x burn.
  • Mitigation Targets turns each burn target into an Error ratio ceiling and Required reduction, which helps quantify how much the error ratio must drop to clear a page or ticket threshold.
  • Alert Windows shows the configured threshold, the triggering error ratio, whether the current burn crosses it, and how much of the budget that threshold spends in its long window.
  • Budget Runway Curve plots remaining budget across the SLO window at the current burn rate.
  • Burn Alert Ladder compares the current burn line with the configured alert thresholds.

A high burn multiple does not prove the service is still failing. It says the entered error ratio would spend budget quickly if it continued. Confirm that the lookback window still reflects active traffic, then compare the result with logs, deploy history, regional split, and user-visible symptoms before paging a team or blocking a release.

The most useful next action is usually tied to Required reduction. If the Mitigation Targets row says the sustained page clears at 0.600% error ratio and the current value is 0.800%, the incident target is not vague: the bad-event ratio needs to fall by about 0.200 percentage points before that threshold clears.

Step-by-Step Guide:

Work from the SLO definition to the current error sample, then use the result tabs to verify urgency and mitigation targets.

  1. Enter Service or SLO name with the label used in dashboards and incident notes. The same label appears in Service / SLO slice and the export payload.
  2. Set Availability SLO. If the value is 100%, 0%, or otherwise outside the valid range, the validation area shows Availability SLO must be greater than 0 and less than 100 percent.
  3. Set SLO window in days. This controls Budget consumed per hour, Runway to exhaustion, Fresh full-budget runway, and the budget-spend values in Alert Windows.
  4. Enter Current error ratio and Budget remaining. If the remaining budget is already 0%, the summary changes to Error budget already spent.
  5. Set Observed window to the metric lookback behind the error ratio. Fix any zero or negative value before trusting Observed-window budget spend.
  6. Open Advanced only when your team uses different burn thresholds. The default controls are Fast page burn 14.4x, Sustained page burn 6x, Ticket burn 3x, and Slow ticket burn 1x.
  7. Read the summary, then verify Current burn rate and Runway to exhaustion in Burn Ledger. Use Mitigation Targets for the required error-ratio reduction and Alert Windows for threshold crossings.
  8. Use Budget Runway Curve, Burn Alert Ladder, and JSON after the table values match the incident or review scenario you mean to share.

Interpreting Results:

Current burn rate is the headline urgency signal. At 1.00x, the entered error ratio matches the SLO allowance. Below 1.00x, the service is spending less budget than the full window can sustain. Above 1.00x, the same error ratio would exhaust a fresh full budget before the SLO window ends.

Runway to exhaustion is often the better incident-room number because it includes Budget remaining now. A 6.00x burn with 95% remaining budget gives more time than a 2.00x burn with 5% remaining. Treat the runway as a straight-line estimate, not a forecast that traffic and failures will stay unchanged.

Output Use it for Do not overread
Current burn rate Comparing the current bad-event ratio with the sustainable SLO allowance. It does not identify the failing component or prove the issue is still active.
Budget consumed per hour Estimating how much of the full period budget disappears each hour at the current pace. It is not a count of user-facing failures.
Runway to exhaustion Estimating time until the remaining budget reaches zero if burn stays unchanged. It is not a promise that the budget will actually last that long.
Observed-window budget spend Checking how much of the full budget the current lookback would consume. It changes when the observed window changes, even if the error ratio is unchanged.
Error ratio at 1x burn Finding the error-ratio ceiling for sustainable burn under the selected SLO. It does not say lower error ratios are healthy in every user segment.
Maximum possible burn Seeing the theoretical burn if every eligible event failed. It can make some high threshold choices impossible when the SLO target leaves a large error budget.

When an alert row says Above 100% error ratio or a target row says the policy threshold exceeds the possible error ratio, the chosen threshold cannot be reached for that SLO. For example, a 90% SLO has a 10% error budget, so a 14.4x threshold would require a 144% error ratio. Lower the threshold or use a stricter SLO if that alert route needs to be reachable.

Worked Examples:

Default checkout API burn

With Service or SLO name set to checkout-api availability, Availability SLO at 99.9%, SLO window at 30 days, Current error ratio at 0.800%, Budget remaining at 62%, and Observed window at 1 hour, Current burn rate is 8.00x. The summary crosses the sustained page threshold, Budget consumed per hour is 1.111%, Runway to exhaustion is about 2.3 days, and Observed-window budget spend is 1.111% of the full budget.

Fast page pressure from a sharp spike

Keep the 99.9% SLO and 30-day window, then change Current error ratio to 1.500% and Budget remaining to 80%. The burn becomes 15.00x, which exceeds the default Fast page burn threshold of 14.4x. Alert Windows shows the fast page Error ratio trigger at 1.440%, and Runway to exhaustion falls to about 1.6 days if that error ratio continues.

Validation catches an impossible SLO

If Availability SLO is entered as 100%, the result area stops on Burn-rate inputs need review and the validation message says Availability SLO must be greater than 0 and less than 100 percent. No Budget Runway Curve or alert comparison should be used until the target is corrected, because a 100% SLO leaves a zero error budget for division.

FAQ:

Is burn rate the same as error ratio?

No. Current error ratio is the observed percentage of bad events. Current burn rate divides that error ratio by the SLO allowance, so 0.8% errors become 8.00x burn under a 99.9% SLO.

Why does runway change when budget remaining changes?

Runway to exhaustion uses the current burn pace and the entered Budget remaining. The burn multiple can stay the same while the runway gets shorter as the remaining budget percentage drops.

What does an unreachable alert threshold mean?

It means the threshold burn multiplied by the SLO error budget would require more than 100% bad events. The Alert Windows row then shows Above 100% error ratio, and the matching mitigation row explains that the policy threshold exceeds the possible error ratio.

Does the result check my monitoring system?

No. The calculation uses the values you enter. It does not verify a live SLO, fetch metric series, or decide which events are eligible, so the input values should come from the same monitoring query and SLO policy you plan to defend.

Why did the input review message appear?

The validation area appears when a required numeric value is outside the accepted range, such as an SLO not greater than 0 and less than 100, an error ratio outside 0% to 100%, a budget remaining value outside 0% to 100%, or an observed window that is not greater than 0 hours.

Glossary:

Service-level indicator (SLI)
The measured reliability signal, such as the share of eligible requests that succeed.
Service-level objective (SLO)
The target success percentage over a defined window, such as 99.9% availability over 30 days.
Error budget
The allowed failure percentage left by the SLO, calculated as 100% minus the SLO target.
Burn rate
The current error ratio divided by the allowed error budget percentage.
Observed window
The lookback duration behind the current error ratio, used to estimate observed-window budget spend.
Budget runway
The estimated time until the remaining error budget reaches zero if the current burn continues.
Alert window
A burn threshold with a long-window label, route, and budget-spend estimate used for page or ticket decisions.

References: