Incident SLO impact
How the auto-impact panel computes burn rate and time to budget exhaustion.
When an incident lists affected services, every SLO bound to those services contributes to the auto-impact panel. The panel updates every 30 seconds while an incident is open and freezes on resolve.
What gets computed
For each affected SLO:
- Burn during incident: total seconds the metric was
unhealthybetween the incident'spublished_atand eitherresolved_ator now, whichever is earlier. - Percent of budget consumed: burn seconds divided by the SLO's total budget seconds. Total budget = window seconds × (1 − target%).
- Total budget remaining: the last-computed budget percentage from the periodic evaluator, not recomputed in the panel. It may be a few minutes stale.
- Time to exhaust: at the current burn rate (burn seconds / incident duration seconds), how long until the remaining budget reaches zero. Reported in minutes; null when the burn rate is zero.
Caching
Repeated panel polls within 30 seconds reuse the same computation (in-memory cache keyed by incident id). This keeps an open dashboard that polls every 30s from triggering redundant recomputation.
Sources of error
- Recorded metric history is the source of truth for burn. If the agent missed pushes during the incident, those gaps are not counted as unhealthy.
- The remaining-budget % comes from the most recent run of the periodic evaluator. If evaluation fell behind, the value can be stale by a few minutes. The burn-during-incident value is always fresh.
- Time-to-exhaust extrapolates a linear burn rate. Real systems rarely sustain a linear rate; treat the number as a rough budget rather than a precise countdown.
Public visibility
The auto-impact panel is console-only by default. A per-incident toggle exposes a slimmed view (burn % only, no time-to-exhaust) on the public incident page. Some operators choose to surface it for transparency; others view it as internal-only. The default is off.