Issues and alerting

This section covers three things that sound alike and answer different questions.

• An issue is what your application's own signals produce. Error-severity logs and error-status spans are fingerprinted and grouped, so the same error occurring a thousand times is one issue, not a thousand. Issue policies decide which errors qualify and how many occurrences it takes before a fingerprint becomes a visible issue.
• An alert is what a rule produces. A rule is a threshold condition over a metric you emit (avg(http_request_duration_ms) > 800 for 5m, for example). While the condition holds, the alert is firing; while it does not, it is ok. Alerts can be muted with a silence without changing their underlying state.
• An incident is what a human, or a monitor check, or a firing rule, declares as a real event with a start and (usually) an end. Incidents have a lifecycle, SLA timers and an escalation policy that pages people until one of them acknowledges it.

None of the three promotes automatically into another. An issue does not become an incident on its own; a rule condition or a monitor check does that. Resolving an issue does not close an incident it happens to relate to, and resolving an incident does not touch the issue. They are linked for cross-reference (an issue can point at the incident on the same service; an incident originated from a rule points back at the alert), but each keeps its own status and its own history.

Notifications are how any of this reaches you: mobile push only, controlled by a per-member schedule, with escalation pages bypassing that schedule on purpose.