alerting-doctrine

# alerting-doctrine ## When to use Use when classifying an alert, reviewing an alert set, or deciding whether a condition should wake a human. Provider-neutral: the classes below hold whichever tool evaluates the rule. Do NOT use when: - Establishing which signals exist at all (use `logging-monitoring` first — you cannot alert on a signal the project does not have) - Adjudicating a go/no-go verdict (use `operational-readiness`) - Running an incident once it has started (use `incident-commander`) - Building the dashboard the alert links to (use `dashboard-design`, `grafana`) ## The three classes Every alert is exactly one of these. The class is decided by **what the recipient must do**, never by how alarming the condition sounds. | Class | Condition that earns it | Destination | Latency of response | |---|---|---|---| | `page` | A human must act **now** or the damage grows | Wakes a named human | Minutes | | `action` | A human must act, but the next working day is soon enough | Ticket or queue | Hours to days | | `info` | Nobody must act; it is context for when something else fires | Log, channel, dashboard | Never | **What earns a `page`** — all three, as a condition rather than a preference: 1. **User-visible or irreversible.** Users are affected now, or damage accumulates while nobody looks (data loss, budget burn, a queue filling toward a ceiling). 2. **Actionable now.** A named human can do something about it at 3am. "The upstream provider is down" is n...