Vorfälle

Ein Vorfall ist die Geschichte einer Störung: was passiert ist, was du tust, wann es vorbei war. Er hat eine eigene Seite, erscheint auf der Statusseite und im Verlauf, und löst — wenn du es willst — Benachrichtigungen aus.

Die vier Phasen

Status Wofür
Untersuchung Etwas ist kaputt, die Ursache ist offen.
Identifiziert Ursache bekannt, Behebung läuft.
Beobachtung Behoben, wir schauen noch, ob es hält.
Behoben Erledigt.

Die Reihenfolge ist eine Empfehlung, kein Zwang — du kannst direkt auf Behoben springen, wenn die Störung vorbei war, bevor du sie melden konntest.

Sobald du auf Behoben setzt, wird der Lösungszeitpunkt gesetzt und die betroffenen Komponenten gehen zurück auf betriebsbereit.

Schweregrad

Gering, Schwerwiegend, Kritisch. Der Schweregrad beschreibt, wie sehr es weh tut — unabhängig davon, in welcher Phase die Bearbeitung ist. Er steuert die farbliche Hervorhebung auf der Seite.

Die Uptime rechnet nicht mit dem Schweregrad, sondern mit dem Zustand der betroffenen Komponenten. Siehe Uptime.

Was du einstellst

  • Titel — was in der Liste und in der Benachrichtigung steht. Beschreibe die Wirkung, nicht die Ursache: „Login schlägt fehl" hilft mehr als „Redis-Cluster degraded".
  • Meldung — der erste Update-Text, formatierbar. Über die API und MCP darfst du HTML schicken: Absätze, Hervorhebungen, Listen, Überschriften und Links bleiben; Skripte, Event-Handler, iframes, Inline-Styles und javascript:-Links entfernen wir beim Speichern. Das gilt genauso für Updates, Wartungen und Vorlagen.
  • Betroffene Komponenten — sie nehmen den Zustand an, den der Schweregrad vorgibt: Gering → teilweiser Ausfall, Schwerwiegend und Kritisch → großer Ausfall. Über die API kannst du stattdessen je Komponente einen eigenen Zustand mitgeben. Damit färbt sich die Statusseite passend ein.
  • Zeitpunkt — wann es begonnen hat. Standard ist jetzt; du kannst zurückdatieren, wenn du erst später zum Melden kommst. Über die API trägst du für einen nachträglich gemeldeten, schon gelösten Vorfall auch das Ende ein (resolved_at) und korrigierst beides später.
  • Sichtbar — aus heißt: der Vorfall existiert nur für dein Team. Er steht nirgends auf der Statusseite, auch seine eigene Seite ist weg; die Komponenten behalten ihren Zustand, und niemand wird benachrichtigt, auch nicht deine Chat-Integrationen. Zum Vorbereiten. Schaltest du ihn bei einem offenen Vorfall ein, passiert alles in diesem Moment: die Komponenten zeigen die Störung, Abonnenten und Chat erfahren davon. Einen schon gelösten Vorfall nachträglich sichtbar zu schalten, verschickt nichts. Schaltest du einen bereits sichtbaren Vorfall wieder aus, verschwindet er von der Seite; die Komponenten zeigen die Störung weiter, bis du ihn löst oder sie aus dem Vorfall nimmst. Schaltest du ihn danach wieder ein, wird er nicht ein zweites Mal angekündigt.
  • Angepinnt — stellt einen offenen Vorfall auf der Statusseite vor die anderen offenen, auch wenn diese neuer sind. Gelöste Vorfälle stehen im Verlauf nach Datum.
  • Abonnenten benachrichtigen — schickt die Meldung an deine Abonnenten. Siehe Abonnenten.
  • Nicht gelistet und Nicht auf die Uptime anrechnen — siehe Nicht gelistete Einträge.

Updates

Ein Vorfall lebt von seinen Updates. Jedes bekommt einen eigenen Zeitstempel und erscheint auf der Vorfallseite als Verlauf.

Beim Schreiben eines Updates kannst du gleichzeitig den Status ändern — „Identifiziert: Ursache war ein fehlerhaftes Deployment, Rollback läuft" ist ein Update und ein Statuswechsel in einem Schritt.

Auch je Update entscheidest du, ob Abonnenten benachrichtigt werden. Nicht jede Zwischenmeldung muss eine Mail auslösen.

Im Formular und in der Liste findest du Link kopieren — die Adresse der Vorfallseite unter deiner Statusseiten-Domain. Die kannst du in ein Ticket, eine Mail oder einen Chat geben.

Freigabe durch eine zweite Person

Ist für deine Statusseite das Vier-Augen-Prinzip aktiv, geht ein neuer Vorfall zuerst in die Warteschleife — er erscheint erst auf der Seite und löst erst Benachrichtigungen aus, wenn jemand anderes freigegeben hat.

Vorlagen

Wiederkehrende Störungen schreibst du nicht jedes Mal neu — siehe Vorlagen.

Über die API

Vorfälle sind der Grund, aus dem es die API gibt: Dein Monitoring oder deine CI kann sie anlegen und schließen, ohne dass jemand ein Dashboard öffnet.

# Anlegen
curl -X POST https://statuswerk.eu/api/v1/incidents \
  -H "Authorization: Bearer $STATUSWERK_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "title": "Erhöhte Fehlerrate im Checkout",
    "message": "Wir untersuchen erhöhte 500er im Checkout.",
    "severity": "major",
    "components": [{"id": "...", "status": "partial_outage"}]
  }'

# Update nachschieben
curl -X POST https://statuswerk.eu/api/v1/incidents/{id}/updates \
  -H "Authorization: Bearer $STATUSWERK_TOKEN" \
  -d '{"message": "Ursache gefunden, Rollback läuft.", "status": "identified"}'

# Schließen
curl -X PATCH https://statuswerk.eu/api/v1/incidents/{id}/resolve \
  -H "Authorization: Bearer $STATUSWERK_TOKEN"

Vollständig in der API-Referenz.