Erstellen Sie ein vollständiges, schuldfreies Post-Mortem aus einer rohen Incident-Timeline
Why this prompt matters
Post-mortems that skip the root cause / contributing factors distinction produce action items that fix symptoms, not systems. Teams that consistently write shallow post-mortems repeat the same incident categories — different service, same missing circuit breaker, same absent alert. The blameless framing is also not optional: post-mortem cultures where engineers feel implicitly blamed for outages produce teams that under-report near-misses, which means preventable P0s go undetected until they actually happen.
What we use it for
Your team resolved a P0 outage two hours ago. The on-call engineer has a Slack thread, a PagerDuty timeline, and some runbook notes — but nothing structured. You need a complete post-mortem document ready for the engineering all-hands tomorrow morning, and you have thirty minutes.
Prompt
Act as a senior site reliability engineer with extensive experience writing blameless post-mortems for high-traffic systems.
Context:
The following incident has been resolved. You have been given a raw timeline of events, the contributing factors identified during the retrospective, and the remediation steps the team took.
Incident details:
- Service affected: [SERVICE NAME, e.g., "Payment API", "User Authentication Service"]
- Severity: [P0/P1/P2]
- Duration: [START TIME] to [END TIME] ([TOTAL DURATION])
- Customer impact: [DESCRIBE IMPACT, e.g., "100% of checkout requests failed for 47 minutes"]
- Raw timeline / notes: [PASTE YOUR INCIDENT NOTES, SLACK THREAD, OR RUNBOOK ENTRIES HERE]
Task:
Write a complete, professional blameless post-mortem document following Google's SRE post-mortem culture principles. The document must identify system failures and process gaps — never individual blame.
Constraints:
- Use blameless language throughout. Say "the deployment pipeline did not have a gate for X" not "the engineer forgot to check X"
- Distinguish between root cause (the fundamental system or process failure) and contributing factors (conditions that allowed the root cause to have impact)
- Action items must be specific, ownable, and measurable — not vague ("improve monitoring")
- Do not pad the timeline. Only include events that affected the incident trajectory
- If the raw notes contain blame language, neutralize it in the post-mortem
Output Format:
**Incident Post-Mortem: [INCIDENT TITLE]**
**Date:** [DATE] **Severity:** [P0/P1/P2] **Duration:** [X hours Y minutes] **Status:** Resolved
**Executive Summary**
[2-3 sentences: what failed, for how long, customer impact, and status]
**Timeline** (all times in [TIMEZONE])
[Chronological bullet list: time → what happened / who detected it / what action was taken]
**Root Cause**
[Single paragraph identifying the fundamental system or process failure. No blame language.]
**Contributing Factors**
[Bulleted list: each factor that allowed the root cause to cause impact]
**Impact**
[Quantified: % of users affected, requests failed, revenue exposure if known, SLA breach if applicable]
**What Went Well**
[Honest assessment: detection speed, communication, rollback success, etc.]
**What Went Poorly**
[Honest, blameless assessment: slow escalation paths, missing runbooks, unclear ownership, etc.]
**Action Items**
| Priority | Action | Owner Role | Due |
|---|---|---|---|
| P0 | [Specific action] | [Role, not name] | [DATE] |
**Lessons Learned**
[2-3 sentences: the systemic lesson this incident teaches, framed for future decision-making]Result
**Incident Post-Mortem: Payment API Outage — Connection Pool Exhaustion** **Date:** 2026-05-14 **Severity:** P0 **Duration:** 1 hour 23 minutes **Status:** Resolved
**Executive Summary** A deployment of Payment API v4.17.2 introduced a database query that did not release connections under timeout conditions, exhausting the PostgreSQL connection pool within 34 minutes of deploy. Checkout requests failed for 100% of users between 14:02 and 15:25 UTC. No payment data was lost; all in-flight transactions were rolled back cleanly by PostgreSQL.
**Timeline** (all times UTC) - 13:31 — Payment API v4.17.2 deployed to production via automated pipeline. Health checks passed. - 13:58 — First spike in payment_api_p99_latency (180ms → 2.4s). Alert fires to on-call channel. - 14:02 — db_pool_available_connections hits zero. Checkout endpoint returns 503 for all requests. - 14:09 — On-call engineer identifies connection pool exhaustion in Datadog. Escalates to database team. - 14:17 — Database team identifies new query in v4.17.2 as source of leaked connections. Initiates rollback. - 14:31 — Rollback to v4.17.1 begins after second-engineer sign-off. - 14:37 — Rollback complete. Connection pool begins recovering. - 15:25 — All metrics return to baseline. Incident resolved.
**Root Cause** The new getPaymentMethodDetails() query introduced in v4.17.2 opened a database transaction but did not include a timeout handler for the network I/O path. Under elevated latency from the payment provider API (which was experiencing independent slowdowns), the transaction blocked indefinitely without releasing its connection back to the pool. With no connection limit per query type and no circuit breaker on the I/O path, the pool exhausted completely within 34 minutes of the deploy.
**Contributing Factors** - The CI pipeline had no static analysis check for connection lifecycle management in database queries - The staging environment uses a connection pool 10× smaller than production, masking this failure mode at staging load - The rollback approval process requires a second engineer sign-off with no defined fast-path escalation, adding 14 minutes to recovery time - No alert existed for connection pool availability below 20%; the first alert fired only after the pool was already fully exhausted
**Impact** - 100% of checkout requests failed for 83 minutes - ~14,200 failed checkout attempts (at pre-incident rate of 171/min) - No SLA breach (threshold: 120 minutes for P0 incidents) - No payment data loss; all in-flight transactions rolled back cleanly
**What Went Well** - Latency alerting fired within 27 minutes of deploy — well within the team's 30-minute detection target - Database team identified the specific query responsible within 8 minutes of escalation - The rollback itself executed in 6 minutes with no secondary failures or data inconsistencies
**What Went Poorly** - The rollback approval gate added 14 minutes with no fast-path for P0 incidents during peak hours - No connection pool headroom alert meant the service transitioned from 100% available to 0% with no intermediate warning - The PR review checklist does not include connection lifecycle verification for database query changes
**Action Items** | Priority | Action | Owner Role | Due | |---|---|---|---| | P0 | Add alert for db_pool_available_connections below 30% | On-Call Infrastructure | 2026-05-21 | | P0 | Define P0 fast-path rollback approval (max 5 min, auto-escalate) | Engineering Manager | 2026-05-21 | | P1 | Add CI linting rule for unguarded database transactions | Backend Platform | 2026-05-28 | | P1 | Scale staging connection pool to 1:3 ratio of production | Database Reliability | 2026-06-04 | | P2 | Add timeout handler to all payment provider I/O paths | Payments Team | 2026-06-11 |
**Lessons Learned** Connection lifecycle management requires both explicit code review verification and automated tooling — relying on developer attention alone is insufficient at current deployment frequency. The contributing factors identified here (missing alerts, undersized staging, slow rollback gates) are systemic patterns worth auditing across all critical services, not just the payment stack.
Post-Mortems, die unter Zeitdruck oder Tage nach dem Abklingen des Adrenalins verfasst werden, sind oft oberflächlich. Sie übersehen Contributing Factors, ignorieren die systemischen Muster, die den Incident ermöglicht haben, oder weisen stillschweigend Schuld zu durch Wortwahl. Dieser Prompt erzwingt die Struktur, die Post-Mortems wirklich nützlich macht: schuldfreie Sprache, Root Cause getrennt von Contributing Factors, und Maßnahmen, die spezifisch genug sind, um abgeschlossen zu werden.
Der Prompt
Kopieren Sie dies vollständig. Ersetzen Sie jedes eingeklammerten Feld durch Ihre tatsächlichen Incident-Details, bevor Sie es ausführen.
Handeln Sie als Senior Site Reliability Engineer mit umfassender Erfahrung im Verfassen schuldfreier Post-Mortems für Hochlastsysteme.
Kontext:
Der folgende Incident wurde behoben. Ihnen wurden eine rohe Timeline der Ereignisse, die während des Retrospektivs identifizierten Contributing Factors und die vom Team ergriffenen Remediationsschritte zur Verfügung gestellt.
Incident-Details:
- Betroffener Service: [SERVICE NAME, z.B. "Payment API", "User Authentication Service"]
- Schweregrad: [P0/P1/P2]
- Dauer: [STARTZEIT] bis [ENDZEIT] ([GESAMTDAUER])
- Auswirkung auf Kunden: [BESCHREIBEN SIE DIE AUSWIRKUNG, z.B. "100 % der Checkout-Anfragen schlugen 47 Minuten lang fehl"]
- Rohe Timeline / Notizen: [FÜGEN SIE HIER IHRE INCIDENT-NOTIZEN, DEN SLACK-THREAD ODER RUNBOOK-EINTRÄGE EIN]
Aufgabe:
Verfassen Sie ein vollständiges, professionelles, schuldfreies Post-Mortem-Dokument nach den Prinzipien der Post-Mortem-Kultur von Google SRE. Das Dokument muss Systemfehler und Prozesslücken identifizieren – niemals individuelle Schuld zuweisen.
Einschränkungen:
- Verwenden Sie durchgängig schuldfreie Sprache. Sagen Sie "die Deployment-Pipeline hatte kein Gate für X" nicht "der Ingenieur vergaß, X zu prüfen"
- Unterscheiden Sie zwischen Root Cause (dem grundlegenden System- oder Prozessfehler) und Contributing Factors (Bedingungen, die es dem Root Cause ermöglichten, Auswirkungen zu haben)
- Maßnahmen müssen spezifisch, verantwortbar und messbar sein – nicht vage ("Monitoring verbessern")
- Füllen Sie die Timeline nicht auf. Nehmen Sie nur Ereignisse auf, die den Incident-Verlauf beeinflusst haben
- Wenn die rohen Notizen Schuldsprache enthalten, neutralisieren Sie diese im Post-Mortem
Ausgabeformat:
**Incident Post-Mortem: [INCIDENT TITLE]**
**Datum:** [DATUM] **Schweregrad:** [P0/P1/P2] **Dauer:** [X Stunden Y Minuten] **Status:** Behoben
**Executive Summary**
[2-3 Sätze: Was fiel aus, wie lange, Auswirkung auf Kunden, Status]
**Timeline** (alle Zeiten in [ZEITZONE])
[Chronologische Aufzählung: Zeit → was passierte / wer entdeckte es / welche Aktion wurde ergriffen]
**Root Cause**
[Ein Absatz, der den grundlegenden System- oder Prozessfehler identifiziert. Keine Schuldsprache.]
**Contributing Factors**
[Aufzählung: jeder Faktor, der es dem Root Cause ermöglichte, Auswirkungen zu haben]
**Auswirkungen**
[Quantifiziert: % der betroffenen Nutzer, fehlgeschlagene Anfragen, Umsatzexposition falls bekannt, SLA-Verletzung falls zutreffend]
**Was gut lief**
[Ehrliche Bewertung: Erkennungsgeschwindigkeit, Kommunikation, Rollback-Erfolg usw.]
**Was schlecht lief**
[Ehrliche, schuldfreie Bewertung: langsame Eskalationspfade, fehlende Runbooks, unklare Verantwortlichkeiten usw.]
**Maßnahmen**
| Priorität | Maßnahme | Verantwortliche Rolle | Fällig |
|---|---|---|---|
| P0 | [Spezifische Maßnahme] | [Rolle, nicht Name] | [DATUM] |
**Lessons Learned**
[2-3 Sätze: die systemische Lektion, die dieser Incident lehrt, formuliert für zukünftige Entscheidungen]Warum jeder Abschnitt da ist
Die Unterscheidung zwischen Root Cause und Contributing Factors ist die wichtigste strukturelle Entscheidung in diesem Prompt. Ohne sie schreiben Teams "die Datenbank fiel aus" als Root Cause und betrachten den Fall als erledigt. Der Prompt zwingt Sie, tiefer zu graben: Welche Eigenschaft des Systems machte es möglich, dass "die Datenbank ausfällt"? Gab es keinen Circuit Breaker? Keinen Connection-Pool-Alarm? Eine zu kleine Staging-Umgebung, die den Fehler maskierte? Das sind die Contributing Factors – und genau das, was Sie tatsächlich beheben.
Schuldfreie Sprache ist eine Einschränkung, keine Ton-Präferenz. Der Prompt weist das Modell explizit an, Schuldsprache zu neutralisieren, falls sie in den eingefügten rohen Notizen auftaucht. Das ist wichtig, weil rohe Slack-Threads und Incident-Kanäle voller Aussagen wie "John hat den Runbook ohne Überprüfung deployed" sind – was, systemisch umformuliert, zu "die Deployment-Checkliste enthielt keinen obligatorischen Runbook-Review-Schritt für diesen Service-Typ" wird. Die Lösung ist dieselbe, aber eine Version baut eine Kultur auf, in der Ingenieure Beinaheunfälle melden, die andere nicht.
Die Maßnahmentabelle ist bewusst mit Rolle (nicht Name) und Fälligkeitsdatum formatiert. Post-Mortems, die Maßnahmen namentlich zuweisen, scheitern, wenn diese Person das Team verlässt. Die Zuordnung zu einer Rolle macht die Maßnahme dauerhaft durch Organisationsänderungen. Fälligkeitsdaten erzwingen Priorisierung; ohne sie bleiben P1-Maßnahmen monatelang im Backlog.
Beispielausgabe
Hier ist die Ausgabe, die dieser Prompt produziert, wenn er mit einem Connection-Pool-Erschöpfungs-Incident gefüttert wird:
Incident Post-Mortem: Payment API Outage – Connection Pool Exhaustion
Datum: 2026-05-14 Schweregrad: P0 Dauer: 1 Stunde 23 Minuten Status: Behoben
Executive Summary
Ein Deployment von Payment API v4.17.2 führte eine Datenbankabfrage ein, die bei Timeout-Bedingungen keine Verbindungen freigab und den PostgreSQL-Connection-Pool innerhalb von 34 Minuten nach dem Deployment erschöpfte. Checkout-Anfragen schlugen zwischen 14:02 und 15:25 UTC für 100 % der Nutzer fehl. Es gingen keine Zahlungsdaten verloren; alle laufenden Transaktionen wurden sauber zurückgesetzt.
Root Cause
Die neue getPaymentMethodDetails()-Abfrage öffnete eine Datenbank-Transaktion, enthielt aber keinen Timeout-Handler für den Netzwerk-I/O-Pfad. Bei erhöhter Latenz der Zahlungsanbieter-API blockierte die Transaktion unbegrenzt, ohne ihre Verbindung freizugeben. Ohne Verbindungslimit pro Abfragetyp und ohne Circuit Breaker erschöpfte sich der Pool innerhalb von 34 Minuten vollständig.
Contributing Factors
- Die CI-Pipeline hatte keine statische Analyse-Prüfung für das Verbindungslebenszyklus-Management in Datenbankabfragen
- Die Staging-Umgebung verwendet einen 10× kleineren Connection-Pool als die Produktion, sodass dieser Fehlermodus bei Lasttests im Staging-Maßstab nicht auftrat
- Der Rollback-Genehmigungsprozess erforderte die Zustimmung eines zweiten Ingenieurs, was 14 Minuten zur Wiederherstellungszeit hinzufügte, ohne definierte Eskalation, falls der Genehmiger nicht verfügbar war
- Es gab keinen Alarm für eine Connection-Pool-Verfügbarkeit unter 20 % – der erste Alarm löste erst aus, als der Pool bereits erschöpft war
Maßnahmen (Auszug)
- P0: Connection-Pool-Reserven-Alarm bei 30 % Restkapazität hinzufügen – On-Call-Infrastruktur – 2026-05-21
- P0: Fast-Path-Rollback-Genehmigung für P0-Incidents definieren (max. 5 Min.) – Engineering Manager – 2026-05-21
- P1: Linting-Regel zur CI für ungeschützte Datenbank-Transaktionen hinzufügen – Backend-Plattform – 2026-05-28
Das Beste aus dem Prompt herausholen
Die Qualität der Ausgabe skaliert direkt mit der Qualität Ihrer rohen Eingabe. Ein Slack-Thread mit Zeitstempeln und technischen Details erzeugt eine genauere Timeline als eine zusammenfassende Absatzbeschreibung. Wenn Ihre Incident-Notizen dünn sind, fügen Sie einen zweiten Durchlauf hinzu: Nach der ersten Post-Mortem-Ausgabe fordern Sie das Modell auf: "Überprüfen Sie nun die Maßnahmen – sind einige vage oder nicht verantwortbar? Wenn ja, schreiben Sie sie so um, dass sie spezifisch sind." Das Modell wird sie präzisieren.
Für wiederkehrende Incident-Typen (Deploy-bezogene Ausfälle, Datenbankprobleme, Ausfälle von Drittanbieter-APIs) können Sie eine Bibliothek früherer Post-Mortems aufbauen und das Modell bitten, das neue zu vergleichen: "Hier sind drei frühere Post-Mortems aus unserem Payment-Service. Welche Contributing Factors in diesem neuen Incident treten auch in früheren auf?" Dies bringt systemische Muster ans Licht, die einzelne Post-Mortems übersehen.
Claude Opus 4.7 liefert die nuanciertesten schuldfreien Umschreibungen – es erfasst zuverlässig subtile Schuldsprache, die GPT-4o manchmal stehen lässt. Für einfache Incidents mit sauberen rohen Notizen sind Claude Sonnet 4.6 oder GPT-4o schnell und ausreichend.