Severity (Schweregrad)

Jeder Alert und Incident in Incident Management trägt einen Schweregrad (Severity), einen von:

sev1/sev2 alarmieren mit hoher Dringlichkeit, sev3/sev4 mit niedriger Dringlichkeit — die Dringlichkeit bestimmt, welche der Benachrichtigungsketten eines Users feuert (z. B. „sofort Push, nach 5 Minuten SMS" bei hoher Dringlichkeit gegenüber einer langsameren, leiseren Kette bei niedriger). Die Severity bestimmt außerdem, welche deiner Outbound-Integrationen den Incident erhalten, wenn du nach Mindest-Schweregrad routest.

Woher die Severity kommt

Die Severity eines Incidents ist entweder:

• Von seinen Alerts abgeleitet (severityManual: false, der Standard) — die Severity des Incidents ist die höchste (kritischste) Severity über alle in ihn gruppierten Alerts. Ein neuer sev1-Alert auf einem bereits sev3-Incident hebt den gesamten Incident auf sev1 an; der Incident deeskaliert nie stillschweigend, wenn sein schwerwiegendster Alert sich löst.
• Von einem Menschen gesetzt (severityManual: true) — ein manuell erstellter Incident hat keinen Alert-Stream, aus dem sich die Severity ableiten ließe, daher setzt der Ersteller sie direkt, und sie bleibt sticky (die aus Alerts abgeleitete max()-Logik überschreibt sie nie).

Das Payload-Mapping einer Alert-Source kann das eigene Severity-/Priority-Feld eines Anbieters auf sev1–sev4 abbilden (mit einer konfigurierbaren Standard-Severity für nicht gemappte Werte), sodass ein Alert von Datadog, Grafana oder einem benutzerdefinierten Webhook vom Moment der Aufnahme an die richtige Severity trägt.

Routing-Regeln und Kanäle

Eine Routing-Regel oder ein Notification-Channel kann eine minSeverity angeben — der Incident muss mindestens so schwerwiegend sein (mindestens so kritisch oder schlimmer), um sie auszulösen. Der Standard ist sev2, sodass routinemäßige sev3/sev4-Alerts nicht standardmäßig jede konfigurierte Integration erreichen.