Der Vorfall ist geschlossen, der Kanal archiviert, der Postmortem-Entwurf steht bereits — geschrieben nicht vom Bereitschaftsingenieur, sondern von einem Modell, das die Timeline, den Slack-Verlauf und die Untersuchungsdaten gelesen hat. Genau so arbeitet incident.io: Das Template legt fest, welche Abschnitte die KI übernimmt, das Dokument durchläuft In progress → In review → Completed.
Die Anbieterschicht darunter ist in Bewegung. Jeli erreicht am 22. Dezember 2026 das End of Life, die Vorfallanalyse zieht in die Post-Incident Reviews der PagerDuty-Weboberfläche um — vorerst im Early Access. FireHydrant wurde von Freshworks gekauft und geht in deren ServiceOps auf. Das Template überlebt diese Umsortierung, und es entscheidet, was der Agent bekommt und was ein Mensch weiterhin schreiben muss.
Felder zerfallen in zwei Klassen
Ein Teil des Postmortems lässt sich aus Systemen ableiten. Die Timeline entsteht aus Alerts, Deploys und Kanalnachrichten. Detection ergibt sich aus dem Auslösezeitpunkt des Alerts. Impact wird aus Metriken und Statusseite berechnet. Resolution zeigt sich in der Aktion, die die Degradation gestoppt hat. Das alles holt ein Modell ohne menschliche Hilfe heraus, und sorgfältiger als ein Bereitschaftsingenieur um drei Uhr nachts.
Der andere Teil lässt sich nirgendwoher ableiten. Warum die Entscheidung damals richtig aussah. Welche Informationen der Mensch im Moment der Entscheidung hatte. Was fast schlimmer gelaufen wäre und es nicht tat.
| Feld | Woher es stammt | Wer es ausfüllt |
|---|---|---|
| Timeline, Detection, Impact, Resolution | Alerts, Deploys, Metriken, Kanal | Agent |
| Root Causes, Trigger | Hypothesen plus Bestätigung in den Daten | Mensch, Agent hilft |
| Where we got lucky, Lessons Learned | Kopf des Beteiligten | nur Mensch |
| Action Items | Teamentscheidung | nur Mensch |
Der Wert des Ingenieurs im Postmortem ist ans untere Ende dieser Tabelle gerückt. Die oberen Zeilen automatisieren sich, die unteren nicht — und sie machen das Dokument ein halbes Jahr später brauchbar.
Die zwei Felder, die am häufigsten verloren gehen
Das verbreitete Raster der „fünf Fragen“ — was ist passiert, warum, welcher Impact, wie haben wir reagiert, wie verhindern wir eine Wiederholung — ist drei Felder kürzer als das kanonische Template aus dem SRE Book. Zwei davon lohnt es zurückzuholen.
Trigger getrennt von Root Causes. Der Trigger ist der Auslöser („Deploy v2.3.0 um 14:18“). Die Ursache ist, warum das System dafür verwundbar war („eine Migration ohne Index besteht das Review, weil die Checkliste für DB-Änderungen in diesem Repo nicht benutzt wird“). Verschmilzt man beides zu einem Feld, entsteht ein Bestand, in dem Vorfälle im Trigger übereinstimmen und im Mechanismus auseinanderlaufen. Die Suche nach ähnlichen Fällen — per Agent oder per Auge — liefert dann Rauschen.
Where we got lucky. Der einzige Ort, an dem Risiken festgehalten werden, die diesmal nicht gezündet haben: die Tabelle war fast leer, der Vorfall fiel in den Tagesverkehr, die zweite Region blieb zufällig verschont. Das sind keine beobachtbaren Ereignisse — niemand außer einem Beteiligten kann sie aufschreiben. Eine Zeile hier wiegt meist drei Punkte aus Lessons Learned auf.
Das Skelett
Date / Authors / Status — Metadaten, setzt das System
Summary — 3-5 Zeilen für alle ohne Kanal
Impact — Nutzer, Minuten, Geld
Root Causes — warum das System verwundbar war
Trigger — der Auslöser, als eigenes Feld
Resolution — was die Degradation gestoppt hat
Detection — wie wir es merkten und nach wie lange
Action Items — Owner + Deadline, eine pro Zeile
Lessons Learned
What went well
What went wrong
Where we got lucky — nicht überspringen
Timeline — UTC, Fakten ohne Deutung
Supporting information — Graphen, Queries, Links zu PRsDreizehn Abschnitte für einen SEV3 wirken übertrieben — die Hälfte schließt mit einer Zeile ab. Eine leere Überschrift ist ehrlicher als eine fehlende: Sie zeigt, dass die Frage gestellt wurde.
Wann ein Postmortem Pflicht ist
Der Kanon formuliert Trigger als Schwellenwerte statt als Severity-Skala: nutzersichtbare Ausfallzeit oder Degradation über einem Schwellenwert, Datenverlust jeder Größe, Eingriff der Bereitschaft wie Release-Rollback oder Traffic-Umleitung, Auflösungszeit über einem Schwellenwert, Ausfall des Monitorings. Dazu das Recht jedes Stakeholders, eine Analyse anzufordern.
Die Matrix „SEV1/SEV2 — Pflicht“ ist eine lokale Schicht darüber, brauchbar, wenn die Severity bereits durch harte Kriterien festgelegt ist und nicht durch das Bauchgefühl der Bereitschaft. Ein Schwellenwert auf das verbrannte Error Budget gehört in dieselbe Matrix — die Zahl stammt aus eurer Policy, der Kanon gibt sie nicht vor.
Wo Action Items sterben
Ein Punkt ohne menschlichen Owner und ohne Datum ist keine Aktion, sondern eine Formulierung des Bedauerns. Ein Team kann nicht Owner sein: Wo mehrere verantwortlich sind, ist es niemand. Das automatische Anlegen von Tickets aus dem Template beseitigt den einen Schritt, an dem Postmortems abreißen — die Überführung der Entscheidungen ins Tracking.
Ein eigenes Signal sind wiederkehrende Analysen derselben Klasse. Drei Postmortems mit derselben Ursache heißen: Das Problem ist nicht Wissen, sondern fehlende Automatisierung — und ab da zählt es als Toil.
Was sich nicht automatisieren lässt
Ein Modell reproduziert die Struktur, baut die Chronologie und schlägt eine Formulierung der Ursache vor. Es schafft nicht die Bedingungen, unter denen ein Mensch „ich habe den Alert nicht verstanden“ schreibt statt „der Alert war unklar“.
Blameless hat auch eine maschinelle Folge. „Bob hat die Tabelle gelöscht“ gibt einem Agenten nichts: Ein Name ist kein Merkmal. „Das System erlaubte, die Tabelle mit einem Befehl ohne Bestätigung zu löschen“ beschreibt einen Mechanismus, über den sich der nächste gleichartige Fall finden lässt. Ein schuldzuweisendes Postmortem schadet der Kultur und taugt als Datensatz nichts.