Incidents
Incidents bündeln zusammengehörige Alerts zu einem Vorfall. Sie werden automatisch bei kritischen Alerts erstellt (Ausfall der Website, einer Unterseite oder eines Dienstes, Timeout, SSL-Fehler, Safe-Browsing, Blacklist, Security-Score-Einbruch, Defacement, Performance-Budget) und können manuell ergänzt, bestätigt, behoben und dokumentiert werden. Die Timeline zeigt den vollständigen Verlauf — vom ersten Alert über die automatische Diagnose bis zum Postmortem.
Automatische Erstellung
Ein Incident wird automatisch angelegt, sobald ein Alert eines der folgenden Typen feuert: Ausfall (downtime/down), nicht erreichbare überwachte Unterseite (subpage_down), nicht erreichbarer Dienst auf einem Port der Website (service_down), Timeout, ungültiges SSL-Zertifikat (ssl_invalid), Safe-Browsing-Warnung, Blacklist-Eintrag, Security-Score-Einbruch, mögliches Defacement oder Performance-Budget-Verletzung. Andere Alert-Typen (z. B. SSL-Ablauf-Warnung, SEO-Änderung, langsame Antwortzeit) erzeugen nur einen Alert ohne Incident — diese sehen und verwalten Sie unter /app/alerts (Ansehen, Bestätigen, Beheben, Löschen). Existiert für dieselbe Website bereits ein nicht behobener Incident derselben Art, der in den letzten 24 Stunden gestartet wurde, wird der neue Alert daran verknüpft (Timeline-Ereignis „Alert hinzugefügt“) statt einen zweiten Incident zu öffnen. So bleibt ein länger andauernder Vorfall ein einziger Eintrag. Unterschieden werden drei Arten: Erreichbarkeit (Ausfall, Timeout, ungültiges SSL, Unterseite, Dienst), Sicherheit (Safe-Browsing, Blacklist, Security-Score-Einbruch, Defacement) und Performance-Budget. Fällt während eines Ausfalls auch der Security-Score, entsteht dafür ein eigener Incident, der den Ausfall-Incident nicht offen hält. Der Schweregrad wird beim automatischen Anlegen aus dem Alert-Typ abgeleitet: Ausfall, Timeout, ungültiges SSL, Safe-Browsing und Defacement ergeben „Kritisch“, Unterseite, Dienst, Blacklist, Security-Score-Einbruch und Performance-Budget ergeben „Warnung“. Der Titel kombiniert den Alert-Typ mit der betroffenen Website-URL.
Auto-Diagnose bei Erreichbarkeits-Incidents
Wird ein Incident durch Ausfall, Timeout oder „down“ ausgelöst, erfasst XICTRAQ sofort eine leichtgewichtige Momentaufnahme und hängt sie als Timeline-Ereignis „Auto-Diagnose“ an: DNS-Auflösung (A/AAAA, plus die Angabe ob überhaupt aufgelöst wurde — antwortet der Namensdienst gar nicht, steht dort „nicht ermittelt“ statt „nicht aufgelöst“), eine HTTP-Probe (Status-Code, Gesamt- und Verbindungszeit in Millisekunden, primäre IP sowie ausgewählte Antwort-Header wie server, content-type, cf-ray, location), ein Traceroute (tracepath, bis zu 12 Hops, zeigt wo der Pfad bricht) und — falls verfügbar — ein Screenshot der Fehlerseite. Die Diagnose läuft erst nach dem Alert-Versand und verzögert die Benachrichtigung nicht. Sie liefert sofortigen Triage-Kontext: DNS-Problem, 5xx oder ein Netzpfad-Bruch?
Manuell erstellen
Über den Button „Erstellen“ auf der Incidents-Seite legen Sie jederzeit einen Incident manuell an — mit Titel (bis 300 Zeichen) und Schweregrad (Kritisch, Warnung oder Info), optional einer Website zugeordnet. Nützlich für geplante Wartungen oder externe Vorfälle, die nicht durch einen automatischen Alert ausgelöst werden. Ein manuell erstellter Incident startet im Status „Offen“ und erhält ein Timeline-Ereignis „Eröffnet“ mit der Markierung „manuell“.
Lebenszyklus
Ein Incident durchläuft folgende Status: **Offen (Open)** — Gerade erkannt, noch nicht bestätigt. Eskalation läuft. **Untersuchung läuft (Investigating)**, **Ursache identifiziert (Identified)** und **Wird beobachtet (Monitoring)** — optionale Zwischen-Status wie bei professionellen Status-Tools. Sie setzen sie per Status-Update; jeder Wechsel landet als Ereignis „Status-Update“ mit optionaler öffentlicher Notiz (bis 2000 Zeichen) in der Timeline. **Bestätigt (Acknowledged)** — Jemand hat den Incident gesehen und übernommen. Setzt acknowledged_at und acknowledged_by auf dem Incident. Das Stoppen laufender Eskalationen hängt am Alert selbst (Quittierung des Alerts bzw. ACK-Link über alerts.is_resolved), nicht am Incident-Status. **Behoben (Resolved)** — Problem gelöst. Optional mit Ursache (Root Cause, bis 500 Zeichen) und Postmortem (bis 20.000 Zeichen). Alle verknüpften, noch offenen Alerts werden dabei über den zentralen Lifecycle-Dienst mitgeschlossen, sodass der Audit-Trail (delivery_log) konsistent bleibt.
Timeline & Kommentare
Jede Aktion wird als Ereignis in der Timeline protokolliert: Eröffnung, Auto-Diagnose, hinzugefügte Alerts, Status-Updates, Kommentare, Bestätigung, Bearbeitung, manuelle und automatische Behebung. Jedes Ereignis trägt Typ, optionalen Akteur und Zeitstempel. Kommentare (bis 2000 Zeichen) können jederzeit hinzugefügt werden — für interne Kommunikation oder spätere Dokumentation.
Bearbeiten & Löschen
Titel und Schweregrad lassen sich jederzeit anpassen (z. B. Hochstufung von Warnung auf Kritisch). Ein Incident kann vollständig gelöscht werden — dabei wird bei allen verknüpften Alerts die incident_id gelöst, die komplette Timeline (incident_events) entfernt und der Incident-Datensatz selbst gelöscht.
Status-Update-Vorlagen
Drei Vorlagen sind eingebaut (Untersuchung läuft, Ursache identifiziert, Wird beobachtet). Zusätzlich speichern Sie eigene Vorlagen — bis zu 30 pro Konto, je mit Name, optionalem Status (investigating, identified, monitoring, resolved) und vordefiniertem Text (bis 2000 Zeichen). So sind Routine-Meldungen mit einem Klick eingefügt statt jedes Mal neu getippt.
Auto-Resolve bei Recovery
Sobald kein verknüpfter Alert eines Incidents mehr offen ist (Website wieder erreichbar, SSL erneuert, Score erholt), wird der Incident automatisch auf „Behoben“ gesetzt — mit der Ursache „Automatisch behoben“ und einem Timeline-Ereignis „Automatisch behoben“. Das gilt für jeden Resolve-Pfad (Oberfläche, API, Ack-Token, KI-Assistent, automatische Wiederherstellung), nicht nur für die Sammel-Auflösung.
Aufräum-Cron
Ein Aufräum-Job schließt zweierlei: erstens Incidents, deren sämtliche Alerts inzwischen aufgelöst sind (idempotent über denselben Lifecycle-Dienst), zweitens kalte Incidents ohne Timeline-Aktivität seit über 30 Tagen. Diese werden mit der Ursache „Automatisch behoben (inaktiv seit >30 Tagen)“ geschlossen. Offen bleiben in beiden Fällen ein Incident mit noch offenem Alert — der Zustand besteht dann fort, etwa ein weiterhin gefallener Security-Score — und ein manuell angelegter Incident; beide schließt nur jemand von Hand.
Postmortem-Export
Für behobene Incidents lässt sich aus einem verknüpften Alert ein Postmortem erzeugen — strukturierte Dokumentation des Vorfalls für Audits, Kunden-Reports oder das interne Lessons-Learned. Der Download-Button (PDF) erscheint in der Incident-Detailansicht, sobald der Incident behoben ist; als Markdown liefert es die API unter GET /api/alerts/{id}/postmortem.md. Ein manuell angelegter Incident hat keinen verknüpften Alert und damit kein Postmortem.
# API-Endpunkte
Alle Incident-Aktionen sind über die authentifizierte API verfügbar. Die Liste liefert je Abruf höchstens 200 Incidents, die neuesten zuerst; mit limit und offset blättern Sie weiter, total nennt die Gesamtzahl. Filtern lässt sie sich nach Status, Schweregrad (severity) und Website (website_id).
GET /api/incidents?status=open Liste (max. 200 je Abruf, limit/offset)
POST /api/incidents Anlegen (title, severity, website_id?)
GET /api/incidents/{id} Detail + Timeline + verknüpfte Alerts
PATCH /api/incidents/{id} Titel/Severity/Status + optionale Notiz
DELETE /api/incidents/{id} Löschen (löst incident_id der Alerts)
POST /api/incidents/{id}/ack Bestätigen
POST /api/incidents/{id}/resolve Beheben (root_cause?, postmortem?)
POST /api/incidents/{id}/comment Kommentar (comment)
GET /api/incident-templates Eigene Vorlagen lesen
PUT /api/incident-templates Vorlagen ersetzen (max. 30)