Incident Inbox und Message Log

Wie Incidents entstehen, wie Sie sie triagieren und wo jeder Delivery-Versuch auditiert wird.

Incident Inbox und Message Log

DiffMon trennt Change-Triage von Delivery-Diagnostik:

• Incidents (/app/incidents) beantwortet: Was braucht gerade Aufmerksamkeit?
• Message log (/app/message-log) beantwortet: Was wurde gesendet und war es erfolgreich?

Diese Trennung hält laute Transportdetails aus Ihrer Triage-Queue heraus.

Wie Incidents erstellt werden

Ein Incident wird erstellt, wenn ein Monitor-Lauf einen changed-Diff erzeugt und kein passender offener oder acknowledged Incident für denselben Monitor + Fingerprint existiert.

Auf hoher Ebene:

1. Der Worker erstellt für jeden Snapshot-Lauf einen Diff.
2. Wenn der Diff changed ist, verknüpft der Worker ihn mit einem Incident.
3. Existiert kein passender unresolved Incident, wird ein neuer Incident geöffnet.
4. Existiert bereits ein passender Incident, werden lastActivityAt und lastDiffId aktualisiert.

Hinweise:

• baseline_reset-Diffs erzeugen keine Incidents.
• Die Diff-History bleibt immutable, auch wenn Incidents gruppiert werden.

Incident-Status und Operator-Verhalten

open

• Bedeutung: aktive Änderung erfordert Aufmerksamkeit.
• Empfohlene Aktion: letzten Diff und Delivery-Trail prüfen.

acknowledged

• Bedeutung: jemand hat den Incident gesehen, aber er ist noch nicht geschlossen.
• Empfohlene Aktion: verwenden, wenn Ownership klar ist, die Remediation aber noch läuft.

resolved

• Bedeutung: der Incident ist für die Triage geschlossen.
• Empfohlene Aktion: verwenden, nachdem Sie entschieden haben, dass die Änderung akzeptiert oder behoben ist.

Wenn dasselbe Änderungsmuster nach der Auflösung erneut auftritt, kann ein neuer Incident geöffnet werden.

Policy Rules können die Notification-Delivery für passende Änderungen unterdrücken, aber Incidents und Diff-Evidence bleiben bestehen. Details zu Routing und Suppression finden Sie unter Policy Rules.

Wo Sie Details finden

Incidents-Seite (/app/incidents)

Diese Seite ist für Triage und Ownership gedacht:

• Monitor-Kontext (Name + URL)
• Öffnungszeit, letzte Aktivität, Alter
• Referenzen auf ersten und letzten Diff
• Notification-Rollup (sent/failed/destination count)
• Aktionen: Acknowledge, Resolve

Message-log-Seite (/app/message-log)

Diese Seite ist für Transportdiagnostik und Audit gedacht:

• Destination + verwendetes Template
• Delivery-Status und Versuche
• Latenz / HTTP-Status
• Korrelation über diffId / incidentId / requestId
• letztes Response-Snippet oder sanitizierter Fehler

Empfohlener Workflow

1. Starten Sie in Incidents.
2. Öffnen Sie die Incident-Zeile und prüfen Sie Scope, Alter und letzte Aktivität.
3. Wechseln Sie in das nach incidentId gefilterte Message log, wenn Delivery-Verifikation nötig ist.
4. Kehren Sie zum Incident zurück und wählen Sie Acknowledge oder Resolve.

Die wichtigsten Filter

Incidents

• status (standardmäßig unresolved)
• monitor
• direkte incidentId

Message log

• time range
• status
• destination type
• monitor
• incidentId
• requestId

Diese Filter reichen aus, um schnell zu beantworten: "Was hat sich geändert?", "Wer wurde benachrichtigt?" und "Warum ist die Delivery fehlgeschlagen?".