Alerting on Stream Quality: SLOs, Error Budgets, and When to Page a Human
How to turn QoE metrics into actionable alerts — defining SLOs for start time and rebuffering, burn-rate alerting, and avoiding the alert fatigue that makes teams ignore dashboards.
Dashboards don’t wake anyone up — alerts do. But a QoE alerting setup that pages on every blip trains the team to ignore it, which is worse than no alert at all. The goal is a small set of high-signal alerts tied to viewer-visible harm, backed by SLOs and burn-rate logic.
Defining Video SLOs
An SLO is a measurable target for user-visible quality, not a server metric. For streaming, the standard set:
| SLO | Target | Window |
|---|---|---|
| Video start time (p75) | < 1.5s | Rolling 24h |
| Video start failure rate | < 0.5% of sessions | Rolling 24h |
| Rebuffer ratio (p95) | < 1.0% | Rolling 24h |
| Exit-before-start | < 8% | Rolling 24h |
These are user-experience commitments, not uptime guarantees. You can have 100% server uptime and a terrible SLO — which is exactly why SLOs matter.
Burn-Rate Alerting: When to Page
The naive alert is “rebuffer > 1% for 5 minutes.” The problem: real sessions cluster, and a single regional ISP blip fires it constantly without anyone able to act. The fix is multi-window burn-rate alerting:
SLO: rebuffer_ratio_p95 <= 1.0% (error budget = 1.0% of good sessions)
Alert fires when burn rate × window > threshold:
- Fast burn: 14x budget in 1h → page immediately (something is breaking NOW)
- Slow burn: 6x budget in 6h → ticket, not page (investigate this sprint)
A burn-rate alert distinguishes “a bad minute” from “a bad trend.” Fast-burn means the error budget is being consumed so fast you’ll miss the SLO — worth a page. Slow-burn means the trend is bad but not acute — worth a ticket.
“The alert that wakes someone up should answer ‘yes’ to one question: ‘Will the user notice this right now?’ If the answer is no, it belongs in a ticket queue, not a pager.”
The Fatal Combination to Watch
The most dangerous alert pairing is high VSF + high EBVS together — it means viewers are both failing to start and giving up before the failure even registers. That combination points to an upstream problem (CDN degradation, manifest errors, auth wall) that a single-metric alert on either one alone might miss.
Our SLO templates, burn-rate calculation tables, and the escalation matrix for which team gets which alert are in the stream quality alerting and SLO guide.