Articles
SLO Burn-Rate Interview Questions: Multiwindow Alerts and Error Budgets
SLO burn-rate interview guide with multiwindow alert math, error budgets, low-traffic handling, Prometheus logic, and worked examples.
An error rate has no urgency without an objective and a time window. A 1% failure rate is catastrophic for a 99.99% SLO and merely at-budget for a 99% SLO. Burn rate makes that relationship explicit: it measures how quickly the service is consuming its error budget relative to the sustainable rate.
This guide derives the math and then shows why multiwindow alerts combine a fast signal with persistence evidence. For a broader monitoring drill, start with Explain SLI/SLO/SLA and design monitoring.
Evidence boundary: Google's SRE Workbook and Prometheus documentation are official/public technical references. No exact employer interview pattern is claimed because consistent candidate reports were unavailable.
Derive burn rate from the SLO
For a 99.9% availability SLO, the allowed error fraction is:
error budget fraction = 1 - 0.999 = 0.001 = 0.1%
Burn rate is:
burn rate = observed bad-event fraction / allowed bad-event fraction
If 0.1% of requests are bad, burn rate is 0.001 / 0.001 = 1. The service is consuming budget at exactly the sustainable rate. At 1% bad, burn is 10. At 5% bad, burn is 50.
For a 30-day window, a constant burn rate of 1 consumes the budget in 30 days. Burn 14.4 consumes it in about 30 / 14.4 = 2.08 days. A 14.4x burn sustained for one hour spends 14.4 × 1 hour / 720 hours = 2% of the monthly budget.
These calculations assume the SLI denominator and SLO window are defined consistently. If the objective covers eligible API requests, do not divide errors by pods, minutes, or all HTTP traffic. Exclude requests only according to the published SLI contract.
Why one short window is noisy
A five-minute 14.4x alert reacts quickly, but a tiny traffic bucket may contain one failure and appear extreme. A six-hour window is stable but can alert long after a severe incident starts. Multiwindow alerting requires both a long and short window to exceed the same burn threshold.
The Google SRE Workbook presents a practical set for a 99.9% SLO over 30 days:
| Severity | Long window | Short window | Burn rate | Approx. budget spent |
|---|---|---|---|---|
| Page | 1 hour | 5 minutes | 14.4 | 2% |
| Page | 6 hours | 30 minutes | 6 | 5% |
| Ticket | 3 days | 6 hours | 1 | 10% |
The short window is roughly one-twelfth of the long window. The long window proves material budget consumption; the short window confirms the problem is still active. Use AND within each pair and OR across severity pairs.
Conceptually:
(burn_1h > 14.4 AND burn_5m > 14.4)
OR
(burn_6h > 6 AND burn_30m > 6)
If the one-hour window is high but the five-minute window has recovered, a page may no longer be useful. The incident spent budget, but the responder may need a ticket or review rather than an urgent wake-up.
Work a concrete example
Suppose a service has a 99.9% success SLO. Over the last hour it served 1,000,000 eligible requests with 20,000 failures. The error fraction is 2%, so burn is 0.02 / 0.001 = 20.
Over the last five minutes it served 80,000 requests with 1,600 failures. That is also 2%, or burn 20. Both exceed 14.4, so the fast page condition fires.
Now suppose the last five minutes contain 40 failures out of 80,000: 0.05%, burn 0.5. The long window remains 20 because earlier impact dominates, but the short condition is false. The pair does not page. You still record the budget loss and inspect the cause.
For a 99% SLO, the allowed fraction is 1%. The same observed 2% error becomes burn 2, not 20. Burn rate normalizes urgency across objectives.
Define good and bad events before writing PromQL
The hardest part is usually the SLI, not the division. Decide:
- Which requests are eligible?
- Are client errors bad, excluded, or split by cause?
- Do retries count each attempt or the user-visible operation?
- Is latency a threshold SLI, a distribution, or both?
- How are missing metrics treated?
- Does every region and tenant share one objective?
A ratio-based availability SLI might use rate of bad requests divided by rate of eligible requests. Use consistent label filters and aggregation in numerator and denominator. A mismatch can yield a plausible but meaningless percentage.
Prometheus guidance recommends alerting on symptoms and user impact rather than every internal cause. A burn-rate alert should represent user-visible budget consumption. Database CPU or queue depth can support diagnosis but should not substitute for the SLI unless the objective itself is about that signal.
Handle low traffic deliberately
At low volume, one event can dominate a short ratio. The SRE Workbook notes that low-traffic services need special consideration. Options include a minimum event count, a synthetic availability SLI, longer windows, or grouping only where user experience remains meaningful.
A minimum-volume gate reduces noise but can hide total failure of a low-volume critical path. Describe the product consequence. A payroll action used once per day may need synthetic checks and transaction-specific paging rather than request-ratio statistics.
Missing data must not silently mean success. If both numerator and denominator disappear, the ratio may be absent. Add separate telemetry-health alerts where loss of measurement is operationally important.
Avoid averaging ratios incorrectly
Do not average per-instance error percentages unless denominators are equal. One instance with one failure out of one request and another with zero failures out of 999 requests have average instance error 50%, while the fleet error is 0.1%. Sum bad events and total eligible events, then divide.
Likewise, average latency cannot implement a latency SLO such as “99% under 300 ms.” Count events meeting the threshold or use a correctly aggregated histogram. Quantile averages are not fleet quantiles.
When objectives are tenant-specific, a global denominator may hide a small tenant's complete outage. Pair the global SLO with tier, region, or critical-journey objectives where the product contract requires them. Avoid arbitrary high-cardinality alerting that pages separately for thousands of labels.
Connect alerts to the error-budget policy
An error budget is a decision mechanism, not merely a dashboard. Define what happens when consumption is fast, when the service is out of budget, and when data quality is uncertain. A page should have an owner, a first diagnostic view, and an action capable of reducing user harm.
The 14.4x/6x/1x numbers are a starting design, not universal law. Choose thresholds from the SLO window, response expectations, traffic pattern, and tolerance for paging. Backtest against incidents and quiet periods. Measure precision, time to detect, time to resolve, and budget saved rather than celebrating alert count.
If a deployment causes a fast burn, automated rollback may be appropriate when attribution is strong and rollback is safe. If several causes share the SLI, the alert should page a responder instead of guessing. Use deployment markers and exemplars to speed diagnosis.
Translate budget policy into thresholds
You can derive a threshold from the fraction of budget you are willing to spend over the long alert window:
burn threshold = budget fraction to spend × SLO period / long window
For 2% of a 30-day budget in one hour, 0.02 × 720 / 1 = 14.4. For 5% over six hours, 0.05 × 720 / 6 = 6. This derivation is more useful than memorizing numbers because an interviewer can change the SLO period or response policy.
Suppose the SLO uses a rolling 28-day period. If the policy still spends 2% in one hour, the threshold becomes 0.02 × 672 = 13.44. The alert design should update with the policy; copying 14.4 blindly would encode a different trade-off.
For calendar-month objectives, month length changes. Decide whether alert thresholds use a fixed planning duration while reporting uses the calendar, or compute them from the active period. Consistency and understandable response matter more than fake precision.
Discuss reset and remaining-budget traps
Burn rate measures speed, while remaining budget measures position. A service near the end of its window with little budget left may need stricter release policy even if current burn is below a paging threshold. Conversely, a new window does not erase the root cause of an ongoing incident.
Do not divide by remaining budget and call the result standard burn rate without naming the new metric. Keep the normalized SLO burn calculation stable, then add policy using remaining budget, recent trend, and business risk.
If several SLIs share one product objective, define whether their bad events combine into one budget or consume separate budgets. Taking the maximum burn is conservative but differs from aggregating eligible events. The contract must decide before alert code does.
Interview prompts and strong answers
“What does burn rate 10 mean?” The service is consuming error budget ten times faster than the sustainable rate. If constant, a 30-day budget would be exhausted in about three days.
“Why two windows?” The long window establishes material budget impact; the short window confirms the condition remains active. Requiring both reduces pages for brief spikes and already-recovered incidents.
“Why not page on 5% errors?” A raw rate ignores the service objective and denominator. Translate it into burn against the defined SLO and require an actionable persistence window.
“How do you alert at low traffic?” State the statistical instability and product criticality, then choose minimum counts, synthetic checks, longer windows, or journey-specific signals. Do not treat missing requests as healthy.
“How do you validate the alert?” Replay historical metrics, inject synthetic bad events, test exact threshold boundaries and missing data, verify AND/OR grouping, and confirm the runbook and routing.
Test the boolean logic
Use a truth table:
| Scenario | 1h burn | 5m burn | Page? | Reason |
|---|---|---|---|---|
| Sustained severe outage | 20 | 20 | yes | both fast windows exceed 14.4 |
| Recovered severe outage | 20 | 0.5 | no | current short window recovered |
| Tiny current spike | 1 | 20 | no | long window lacks material impact |
| Sustained moderate issue | 7 | 7 | maybe 6h/30m pair | needs the medium windows |
Test equality semantics (> versus >=), zero denominator, counter resets, late samples, label absence, and partial regional telemetry. Verify that recording-rule intervals are short enough for the desired detection time.
Common weak answers
“Burn rate is the error rate” omits normalization by budget. “Page whenever any window is high” destroys the noise benefit. “99.9% means 43 minutes of downtime” assumes downtime rather than event-based errors and uniform traffic. “Use p99 for the numerator” confuses quantile and threshold event counting. “No data is zero errors” can hide monitoring failure.
A concise answer is: “I define eligible and bad events first, derive the allowed error fraction from the SLO, and divide observed bad fraction by it. I pair a long and short window at the same threshold so the alert proves both budget impact and current activity. Then I backtest low traffic, missing data, and boolean boundaries and connect each severity to an actionable response.”