Die meisten Postmortems produzieren ein Dokument, das niemand liest, und Action Items, die niemand ausliefert. Das ist keine Übertreibung. Ich habe Teams dabei zugesehen, wie sie eine Stunde Prosa zu einem Ausfall schreiben, das Dokument in einem Confluence-Bereich mit dem Titel “Incident Reviews 2024 (deprecated)” ablegen und dann, achtzehn Monate später, denselben Ausfall erneut erleben. Das Postmortem wurde geschrieben. Die Incident-Rate hat sich nicht verändert.
Die Lücke zwischen einem geschriebenen Postmortem und tatsächlich weniger Incidents hat meist nichts mit Schuld, Disziplin oder Ehrlichkeit zu tun. Es ist eine Frage des Formats. Die meisten Postmortem-Templates sind aus Googles SRE-Buch übernommen und dann durch ein Dutzend Unternehmen verwässert, von denen jedes eigene Felder ergänzt hat (“Impact Assessment”, “Communication Timeline”, “Customer Comms Log”), ohne zu fragen, ob die neuen Felder künftige Incidents unwahrscheinlicher machen. Das Ergebnis ist ein langes, ritualhaftes Dokument, das an keinen Mechanismus angeschlossen ist, der eine Wiederholung verhindern würde.
Das Format, das ich verwende, ist bewusst kurz. Vier Fragen, die das Dokument beantworten muss, vier Entscheidungen, die das Team treffen muss, und eine Rückkopplungsschleife in die Engineering-Planung. Das war es. Alles andere ist optional und wird meistens übersprungen.
Wofür ein Postmortem eigentlich da ist
Bevor wir zum Format kommen, die Prämisse. Ein Postmortem existiert, um den nächsten Incident unwahrscheinlicher zu machen. Nicht, um zu dokumentieren. Nicht, um Verantwortung zuzuweisen. Nicht aus Compliance-Gründen. Führt das Dokument nicht zu einer Veränderung darin, wie sich das System, der Prozess oder die Organisation verhält, waren es verschwendete Stunden.
Dieses eine Kriterium schneidet das meiste weg, was in typischen Postmortem-Templates steht. Eine zweiseitige Timeline aus Alerts und Slack-Nachrichten, im Nachhinein rekonstruiert, ist meist nicht das, was den nächsten Incident reduziert. Was den nächsten Incident reduziert, ist:
- Die Klasse des Problems gut genug zu verstehen, um das Nächste früh zu erkennen.
- Eine konkrete Änderung auszuliefern (Code, Prozess oder Ownership), die einen der beitragenden Faktoren entfernt.
- Dem Rest des Engineerings von der Fehlerform in einer Form zu erzählen, die sie sich merken können.
- Die Lektion in die bestehenden Planungsrhythmen des Teams zu integrieren, damit sie nicht vergessen wird.
Diese vier Dinge bilden die vier Fragen ab, die mein Postmortem-Format antreiben.
Die vier Fragen
Jedes Postmortem beantwortet diese, in dieser Reihenfolge, auf insgesamt nicht mehr als ein bis zwei Seiten.
1. Was hat der Nutzer erlebt, und wie lange?
Nicht, was das System getan hat. Was der Nutzer gesehen hat. Das steht vorn, weil die Zielgruppe des Postmortems (Sie selbst in sechs Monaten, der Engineer, der nächstes Jahr dazukommt, der Stakeholder, der den Fix finanzieren muss) die Kundenwirkung zuerst vor Augen braucht, um sich für den Rest des Dokuments zu interessieren.
Gute Antworten auf diese Frage sind kurz, konkret und quantifiziert:
Zwischen 14:17 und 14:52 UTC am 15. März 2026 sahen Nutzer, die den Checkout abschließen wollten, eine generische Fehlermeldung und konnten keine Bestellungen absenden. Die Fehlerseite blieb auch bei erneuten Versuchen bestehen. Rund 340 Checkout-Versuche schlugen in diesem Zeitfenster fehl, was etwa 28.000 Euro verzögertem oder verlorenem Umsatz entspricht. Mobiler Traffic war überproportional betroffen (rund 72 Prozent der Fehler kamen von Mobilgeräten).
Schlechte Antworten relativieren, technisieren oder spielen herunter. “Einige Nutzer haben möglicherweise zeitweilige Probleme mit dem Checkout-Service erlebt” ist schlecht. “Kunden konnten 35 Minuten lang nicht auschecken, und wir schätzen einen Umsatzverlust von 28.000 Euro” ist gut.
Diese Frage hat einen zweiten Zweck. Sie zwingt den Postmortem-Verantwortlichen, die Zahlen nachzuschauen. Gibt es keine Zahlen (keine Fehlerrate, keine Anzahl betroffener Nutzer, keine Umsatzabschätzung), lernen Sie das schnell, und das nächste Postmortem wird daran denken, sie zum Zeitpunkt des Incidents zu erfassen.
2. Wie war die Abfolge der Ereignisse, und wo ist unser Modell des Systems gebrochen?
Das ist die Timeline, aber eingerahmt um das mentale Modell des Teams, nicht um den Alert-Stream. Die zu beantwortende Frage an jedem Schritt lautet: Was glaubte der On-Call-Engineer, und wann stellte sich dieser Glaube als falsch heraus?
14:17 · Erster gescheiterter Checkout-Versuch (Kundenbeschwerde). 14:19 · Alert ausgelöst: Checkout-Fehlerrate über 1 Prozent. 14:22 · On-Call bestätigt. Nahm ein Datenbank-Konnektivitätsproblem an, auf Basis einer jüngsten Wartung. Datenbank geprüft; alles gesund. 14:28 · Application-Logs geprüft; Stripe-Webhook-Timeouts gesehen. Stripe-Ausfall angenommen. Stripe-Statusseite geprüft; alles grün. 14:34 · Festgestellt, dass die Webhook-Signaturvalidierung Requests wegen Clock Drift auf dem Webhook-Handler-Pod ablehnt. (Mentales Modell ist hier gebrochen: Wir wussten nicht, dass NTP auf diesem Pod ausfiel, und unsere Dashboards zeigten keinen Clock Drift.) 14:38 · Pod gerollt. Uhr neu synchronisiert. Checkouts wieder möglich. 14:52 · Fehlerrate als normal bestätigt.
So formatiert ist die Timeline eine Geschichte, kein Log. Die Geschichte zeigt auf etwas Konkretes: den Moment, in dem das mentale Modell des Teams versagt hat. In diesem Fall ist “wir wussten nicht, dass NTP auf diesem Pod ausfiel” eine konkrete, behebbare Lücke. Sie wird zum aussichtsreichsten Kandidaten für ein Action Item. “Wir sollten unsere Stripe-Integration verbessern” ist weder konkret noch behebbar; es ist ein vages Bedauern.
Die Gewohnheit, die diese Frage trainiert, ist, Brüche im mentalen Modell als erstklassige Daten zu erfassen. Das erste Mal, als ich dieses Framing in ein Engineering-Team eingeführt habe, haben sich zwei Engineers dagegen gewehrt, weil “wir haben doch schon Timelines”. Drei Monate später hatten sie drei Brüche im mentalen Modell entdeckt, die spätere Incidents vorhergesagt haben, und niemand hat das Format mehr infrage gestellt.
3. Welche beitragenden Faktoren gab es, und warum existierte jeder?
Beachten Sie: beitragende Faktoren, nicht Root Cause. Root Cause ist fast immer eine Fiktion (Richard Cook, “How Complex Systems Fail”: “overt failure requires multiple faults; there is no isolated ‘cause’ of an accident”). Echte Incidents haben vier bis sieben beitragende Faktoren, von denen jeder vorhanden sein musste, damit der Ausfall passiert. Die Fixierung auf eine einzelne “Root Cause” lässt das Postmortem erledigt wirken, während tatsächlich der größte Teil des verfügbaren Hebels verschenkt wird.
Das Format, das ich verwende, listet jeden beitragenden Faktor als Bullet auf, gefolgt von einem kurzen “warum er existierte”-Satz.
Beitragende Faktoren
- Der Webhook-Handler-Pod hatte NTP deaktiviert. Warum: Das Base-Image wurde von einem Utility-Container geforkt, der kein NTP brauchte, und niemand hat die Auslassung beim Deployment bemerkt.
- Clock Drift wurde nicht überwacht. Warum: Unser Metrics-System hat ihn erfasst, aber es war kein Alert konfiguriert. Clock Drift hatte noch nie einen Incident verursacht, also kam niemand auf die Idee, darauf zu alarmieren.
- Die Webhook-Signaturvalidierung hat stillschweigend abgelehnt. Warum: Das Standardverhalten der Stripe-Library ist, ungültige Signaturen mit einer generischen HTTP-Antwort abzulehnen; wir hatten sie nicht mit einem Logger umhüllt, der den spezifischen Fehler in unseren Logs sichtbar gemacht hätte.
- Die Checkout-Fehlermeldungen enthielten keine Request ID. Warum: Der Error-Renderer wurde für Kundenlesbarkeit geschrieben und hat interne Identifier entfernt. Der Customer Support hatte keine Möglichkeit, Nutzerberichte mit Logs zu korrelieren.
Vier Faktoren, vier “Warum”-Antworten. Jeder einzelne, entfernt, hätte den Incident entweder verhindert oder deutlich verkürzt. Das ist nützlich. Das gibt dem Team vier Kandidatenstellen, an denen sich Aufwand lohnt, geordnet nach Kosten und Wirkung.
Die “warum es existierte”-Sätze sind der Teil, der beitragende Faktoren in finanzierbare Arbeit verwandelt. “Clock Drift wurde nicht überwacht” ist eine Lücke; “weil wir die Metrik erfassen, aber keinen Alert konfiguriert haben” ist ein Arbeitspaket von vielleicht zwei Stunden.
4. Was werden wir ändern, und wer verantwortet jede Änderung?
Das ist der einzige Teil, der künftige Incidents reduziert. Alles andere ist Kontext. Der Abschnitt muss konkret sein, verantwortet und datiert.
Änderungen
- NTP zum Base-Image der Webhook-Handler-Pods hinzufügen. Owner: Platform. Ziel: 18. März 2026. Status: nicht begonnen.
- Clock-Drift-Alert bei plus/minus 30 Sekunden auf allen Pods einrichten. Owner: Platform. Ziel: 20. März 2026. Status: nicht begonnen.
- Stripe-Webhook-Signaturfehler mit einem strukturierten Logger-Eintrag umhüllen, der den Rohfehler enthält. Owner: Payments. Ziel: 22. März 2026. Status: nicht begonnen.
- Request ID in Checkout-Fehlerseiten aufnehmen (für Nutzer sichtbar, vom Support korrelierbar). Owner: Checkout. Ziel: 5. April 2026. Status: nicht begonnen.
Vier Punkte, vier Owner, vier Termine. Das ist der Abschnitt, den der Engineering Manager wöchentlich durchgeht, bis alles ausgeliefert ist. Kein Action Item wird zu “fertig” erhoben, bevor es einen gemergten Pull Request und einen kurzen Verweis im Postmortem darauf gibt. Kein Action Item verweilt länger als bis zum Zielkalenderdatum in “in Bearbeitung”, ohne dass eine explizite Begründung ergänzt wird.
Das ist auch der Abschnitt, der die meisten Postmortems im Feld umbringt. Teams schreiben zwölf Action Items, weil sie gründlich sein wollen. Zwei Monate später ist keines erledigt, weil zwölf unrealistisch war. Die Regel, die ich durchsetze: maximal vier Action Items. Haben Sie mehr als vier Fix-Kandidaten, priorisieren Sie, liefern Sie die ersten vier aus und packen Sie den Rest in ein Follow-up-Ticket, über das das Team in der normalen Planung entscheidet.
Die vier Entscheidungen
Die vier Fragen produzieren ein Dokument. Das Dokument ist notwendig, aber nicht hinreichend. Das Postmortem-Meeting (das innerhalb von fünf Arbeitstagen nach dem Incident stattfindet) muss mit vier expliziten Entscheidungen enden.
War das eine Incident-Klasse, die wir schon gesehen haben? Wenn ja, ist das Postmortem zugleich ein Signal, dass der vorherige Fix nicht generalisiert hat. Diese Tatsache wird im Dokument erfasst und für das Technical-Leadership-Review markiert, denn “dasselbe ist zweimal passiert” ist eine andere Kategorie von Problem als “einmaliger Ausfall”.
Muss die Debt-Map aktualisiert werden? Hat das Postmortem eine Region oder einen Pfad ans Licht gebracht, die nicht auf der Technical-Debt-Map des Teams stand (oder die in niedrigerer Schwere markiert war, als sich herausstellt), wird die Map im Meeting aktualisiert, bevor das Meeting endet. Das ist die einzelne wichtigste Rückkopplungsschleife im Prozess, und zugleich die am häufigsten übersprungene. (Das Debt-Map-Format ist in einem früheren Essay beschrieben.)
Müssen wir das breiter teilen? Manche Incidents lehren Lektionen, die andere Teams hören sollten. Ein Postmortem-Text für ein breiteres Engineering-Publikum unterscheidet sich von einem für das unmittelbare Team; er braucht mehr Kontext, weniger insiderhaftes Kürzel. Das Meeting entscheidet, ob die breitere Version geschrieben wird und wer sie verantwortet.
Ist am Postmortem selbst etwas eine Lektion? Hat der Incident eine Lücke darin offengelegt, wie das Team Incidents handhabt (Paging war langsam, das Runbook war falsch, das Dashboard hat das Nötige nicht gezeigt), ist das ein Meta-Action-Item. Es kommt auf eine separate Liste, wird separat nachgehalten und quartalsweise überprüft.
Die Rückkopplungsschleife
Das einzelne Merkmal, das Postmortems, die Incidents reduzieren, von Postmortems, die das nicht tun, unterscheidet, ist dieses: Die Action Items müssen in die normale Planung des Teams zurückfließen, nicht in einem separaten Ticket-System leben, das niemand anschaut.
Der Mechanismus, den ich nutze, ist simpel. Jedes Postmortem-Action-Item wird zu einem Ticket im Haupt-Engineering-Backlog, getaggt mit einem Label (etwa from-postmortem). Diese Tickets laufen in den normalen Sprint-Planungsprozess ein, mit einer Priorität, die der Schwere des Incidents entspricht (rote Incidents heben ihre Action Items in den nächsten Sprint; orange werden bis zum Quartalsende eingeplant; gelbe werden opportunistisch in benachbarter Arbeit erledigt).
Das klingt offensichtlich. In der Praxis ist es auch das, woran die meisten Teams scheitern. Ich habe Action-Item-Tracker gesehen, die in separaten Tabs, separaten Tools, separaten Ritualen lagen, was alles bedeutete, dass sie von der Arbeit getrennt waren, die tatsächlich erledigt wurde. Legen Sie die Punkte dorthin, wo das Team ohnehin hinschaut, sonst wird niemand hinschauen.
Eine zweite Schleife: Das Postmortem speist die Technical-Debt-Map. Beitragende Faktoren, die neue Gefahren aufdecken, oder Gefahren in höherer Schwere als bislang angenommen, werden im Review-Meeting auf der Map platziert. Die Map ist der Ort, an dem das organisatorische Risikogedächtnis lebt; wird sie nicht aktuell gehalten, gewichtet die Planung des nächsten Quartals die Bereiche, die gerade einen Incident verursacht haben, zu niedrig.
Was Sie aus dem üblichen Template streichen sollten
Wenn Sie bislang Postmortems mit einem längeren Template fahren, hier ist, was ich streichen würde, und warum.
Die Executive Summary ganz oben. Sie dupliziert Frage 1. Engineers schreiben die Summary, dann die Frage, haben das Gefühl, sich zu wiederholen, und dann wird die Summary vage, weil sie das zweimalige Schreiben satt sind. Wählen Sie eins. Ich wähle Frage 1.
Die “Detection Timeline” als eigener Abschnitt. Sie gehört in Frage 2 hinein, als Teil der Geschichte. Sie in einen eigenen Abschnitt zu ziehen, erzeugt Redundanz und zerreißt die Erzählung.
Das “Customer Communications Log”. Sofern das Postmortem nicht für eine regulierte Branche oder eine vertragliche SLA ist, ist die Kundenkommunikation nicht das, was den nächsten Incident unwahrscheinlicher macht. Behalten Sie einen Verweis dorthin, wo die Kommunikation lag (Support-Ticket-Thread, Statusseiten-Update), und gehen Sie weiter.
Die “Severity Classification”. Einen Incident als SEV-1 gegenüber SEV-2 einzustufen ist nützlich für die Alert-Routing-Policy und vielleicht für Quartalsmetriken. Für das Postmortem selbst ist es nicht nützlich; wenn Sie schreiben, ist die Schwere bekannt, und die Einstufung ist ein rückblickendes Label. Behalten Sie es im Ticket, nicht im Dokument.
Der Abschnitt “Lessons Learned” getrennt von “Welche Änderungen wir vornehmen”. Ist die Lektion echt, erscheint sie als Action Item. Wenn nicht, ist es eine Plattitüde. “Wir haben gelernt, dass wir bessere Alerts hätten haben sollen” ist eine Plattitüde, sofern kein Action Item einen konkreten Alert ausliefert.
Das schlechteste Postmortem, das ich gelesen habe
Eine konkrete Illustration dessen, was das Format verhindert. Echtes Beispiel, Details verändert.
Das Postmortem war 11 Seiten lang. Es hatte eine vierabsätzige Executive Summary, eine sechsabsätzige Detailed Description, eine minutengenaue Timeline über drei Stunden Slack-Nachrichten und einen “Root Cause Analysis”-Abschnitt, der mit “die Root Cause war ein Konfigurationsfehler” schloss. Der Action-Items-Abschnitt hatte 23 Bullets, die meisten “X untersuchen” oder “Y in Betracht ziehen”.
Ein Jahr später war dieselbe Incident-Klasse zweimal erneut aufgetreten. Ich habe das Postmortem mit dem Team erneut gelesen und drei Fragen gestellt:
- Welche der 23 Action Items sind tatsächlich ausgeliefert worden? (Antwort: vier.)
- Hat eines dieser vier den konkreten Fehlermodus adressiert, der wiederkehrte? (Antwort: nein.)
- Wo ist der Konfigurationsfehler als bekannter Fehlermodus für jeden dokumentiert, der die Config wieder anfassen würde? (Antwort: nirgendwo. Das Wissen steckte im Postmortem, das niemand gelesen hat.)
Das Dokument war auf die falsche Weise gründlich. Es hatte den Anschein von Analyse erzeugt, ohne eines der Ergebnisse zu produzieren, die Analyse eigentlich produzieren soll. Wir haben das Postmortem im kürzeren Format neu geschrieben, sind bei drei Action Items gelandet (die alle innerhalb eines Monats ausgeliefert wurden), und haben einen gepinnten Hinweis an die Konfigurationsdatei selbst gehängt, der die Fehlerklasse erklärt. Der Incident ist seither nicht wiedergekehrt.
Die Tugend ist nicht Tiefe. Die Tugend ist Umsetzbarkeit. Ein kurzes, umsetzbares Postmortem schlägt jedes Mal ein langes, gründliches.
Wann Sie das Postmortem weglassen sollten
Nicht jeder Incident verdient eines. Die Regel, die ich verwende:
- Jeder kundensichtbare Incident mit spürbarer Wirkung: immer.
- Jeder Incident, der knapp daneben war (ein Deployment, das die Produktion fast gebrochen hätte, aber im Canary abgefangen wurde): ja, Kurzversion, fokussiert auf Frage 2 (wo ist das mentale Modell gebrochen).
- Alerts, die ausgelöst haben, ohne Kundenwirkung und ohne systemische Lektion: nein.
- Bekannte zeitweilige Flakes, die das Team bereits akzeptiert hat: nein, aber periodisch überprüfen, ob die Entscheidung “akzeptieren” noch richtig ist.
Die Falle, die zu vermeiden ist, ist Postmortem-Inflation, bei der jeder Alert ein Dokument erzeugt. Wenn Postmortems billig zu überspringen sind, bekommen die geschriebenen die Aufmerksamkeit, die sie verdienen. Werden sie für alles verpflichtend, degradiert das Format zum Compliance-Theater, und die bedeutsamen Postmortems gehen im Rauschen unter.
Die Kadenz, die das Format am Laufen hält
Zwei Kadenzen sorgen dafür, dass das Format Ergebnisse produziert.
Wöchentliches Action-Item-Review. Zehn Minuten im wöchentlichen Team-Sync, geführt vom Engineering Manager. Jedes offene Action Item erhält ein Status-Update. Überfällige Punkte ohne Begründung werden eskaliert. Erledigte Punkte werden mit einem Link zum Pull Request geschlossen. Die Kadenz ist langweilig, und genau deshalb funktioniert sie.
Quartalsweises Format-Review. Einmal pro Quartal sieht sich das Team die letzten Postmortems an und fragt: Produziert das Format noch Ergebnisse? Werden keine Action Items ausgeliefert, kehrt dieselbe Incident-Klasse wieder, wird das Dokument wieder länger, ist etwas abgedriftet. Nachjustieren. Das Format ist nicht heilig; die Ergebnisse sind es.
Diese beiden Rituale zusammen verwandeln “wir machen Postmortems” in “Postmortems reduzieren tatsächlich unsere Incident-Rate”. Ohne sie haben Sie ein Template und einen Confluence-Bereich. Mit ihnen haben Sie eine Rückkopplungsschleife.
Wenn Ihr Team Postmortems schreibt, die Dokumente produzieren, aber nicht weniger Incidents, umfasst mein Business-Alignment-Einsatz ein Audit des aktuellen Formats, der Rückkopplungsschleife in die Planung und der Technical-Debt-Map. Zwei Wochen, um das Ritual zurückzusetzen, ein auf Ihr Team kalibriertes Template und den Rhythmus so eingerichtet, dass Action Items auch wirklich ausgeliefert werden.
Referenzen
- Postmortem Culture: Learning from Failure (Google SRE Book, Kap. 15): die kanonische Darstellung zu schuldfreien Postmortems, Action Items und organisatorischem Lernen aus Incidents.
- How Complex Systems Fail von Richard I. Cook: der kurze Essay, der argumentiert, dass offene Ausfälle stets mehrere Fehler voraussetzen, und der das Framing “beitragende Faktoren, nicht Root Cause” stützt.
- Technical Debt Is a Map, Not a Backlog: der begleitende Essay, der das Debt-Map-Format beschreibt, das die Postmortem-Rückkopplungsschleife aktualisiert.
