alert-ruleslisted

## Overview Alert rules translate "something is wrong" into "the right human knows, with enough context to act". Good alerting is a design discipline: alert on user-impacting symptoms, route by severity and ownership, and ruthlessly eliminate noise. This skill covers alert design patterns that work across monitoring platforms. ## When to use - Writing alert rules for services, error trackers, or infrastructure - Reducing alert noise and fatigue - Choosing between threshold alerts and burn-rate (SLO) alerts - Setting up routing, escalation, and on-call integration - Reviewing an existing alert set for quality ## Core concepts **Alert on symptoms, not causes.** Users experience "checkout is failing", not "CPU is 85%". Symptom alerts (error rate, latency, availability) fire when users hurt; cause metrics (CPU, disk, queue depth) belong on dashboards and as diagnostic context — or as lower-severity warnings when they predict symptoms. **Burn-rate alerting for SLOs.** Multi-window burn rate (fast-burn: 1h/6h windows → page; slow-burn: 1d/3d → ticket) detects real reliability threats with far fewer false positives than static thresholds. It's the gold standard for request-based services; use it wherever you have SLIs. **Severity tiers with distinct responses.** Critical/page: user impact now, human acts immediately. Warning/ticket: degrading or at-risk, handle in working hours. Info:FYI, dashboards only. Every alert declares its tier, and tiers map to notification channels —