Générez un post-mortem complet et sans blâme à partir d’une chronologie brute d’incident
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.
Les post-mortems rédigés sous pression — ou plusieurs jours après que l’adrénaline soit retombée — ont tendance à rester superficiels. Ils omettent les facteurs contributifs, ignorent les schémas systémiques qui ont rendu l’incident possible, ou assignent discrètement un blâme par le choix des mots. Ce prompt impose la structure qui rend les post-mortems réellement utiles : un langage sans blâme, une cause racine distincte des facteurs contributifs, et des actions suffisamment spécifiques pour être clôturées.
Le prompt
Copiez-le intégralement. Remplacez chaque champ entre crochets par les détails réels de votre incident avant de l’exécuter.
Agissez en tant qu'ingénieur senior de fiabilité des systèmes avec une vaste expérience dans la rédaction de post-mortems sans blâme pour des systèmes à fort trafic.
Contexte :
L'incident suivant a été résolu. Vous disposez d'une chronologie brute des événements, des facteurs contributifs identifiés lors de la rétrospective, et des mesures de correction prises par l'équipe.
Détails de l'incident :
- Service affecté : [NOM DU SERVICE, ex. "API de paiement", "Service d'authentification utilisateur"]
- Sévérité : [P0/P1/P2]
- Durée : [HEURE DE DÉBUT] à [HEURE DE FIN] ([DURÉE TOTALE])
- Impact client : [DÉCRIRE L'IMPACT, ex. "100 % des requêtes de paiement ont échoué pendant 47 minutes"]
- Chronologie brute / notes : [COLLEZ VOS NOTES D'INCIDENT, FIL SLACK OU ENTRIES DE RUNBOOK ICI]
Tâche :
Rédigez un document de post-mortem complet, professionnel et sans blâme, en suivant les principes de la culture de post-mortem SRE de Google. Le document doit identifier les défaillances système et les lacunes de processus — jamais le blâme individuel.
Contraintes :
- Utilisez un langage sans blâme dans tout le document. Dites "le pipeline de déploiement n'avait pas de vérification pour X" et non "l'ingénieur a oublié de vérifier X"
- Distinguez la cause racine (la défaillance fondamentale du système ou du processus) des facteurs contributifs (les conditions qui ont permis à la cause racine d'avoir un impact)
- Les actions doivent être spécifiques, attribuables et mesurables — pas vagues ("améliorer la surveillance")
- Ne gonflez pas la chronologie. N'incluez que les événements qui ont affecté la trajectoire de l'incident
- Si les notes brutes contiennent un langage accusateur, neutralisez-le dans le post-mortem
Format de sortie :
**Incident Post-Mortem : [TITRE DE L'INCIDENT]**
**Date :** [DATE] **Sévérité :** [P0/P1/P2] **Durée :** [X heures Y minutes] **Statut :** Résolu
**Résumé exécutif**
[2-3 phrases : ce qui a échoué, pendant combien de temps, impact client et statut]
**Chronologie** (tous les horaires en [FUSEAU HORAIRE])
[Liste chronologique à puces : heure → ce qui s'est passé / qui l'a détecté / quelle action a été prise]
**Cause racine**
[Paragraphe unique identifiant la défaillance fondamentale du système ou du processus. Pas de langage accusateur.]
**Facteurs contributifs**
[Liste à puces : chaque facteur qui a permis à la cause racine de produire un impact]
**Impact**
[Quantifié : % d'utilisateurs affectés, requêtes échouées, exposition financière si connue, violation de SLA le cas échéant]
**Ce qui a bien fonctionné**
[Évaluation honnête : rapidité de détection, communication, succès du rollback, etc.]
**Ce qui a mal fonctionné**
[Évaluation honnête et sans blâme : chemins d'escalade lents, runbooks manquants, responsabilités floues, etc.]
**Actions**
| Priorité | Action | Rôle responsable | Échéance |
|---|---|---|---|
| P0 | [Action spécifique] | [Rôle, pas de nom] | [DATE] |
**Leçons apprises**
[2-3 phrases : la leçon systémique que cet incident enseigne, formulée pour éclairer les décisions futures]Pourquoi chaque section est là
La distinction entre cause racine et facteurs contributifs est la décision structurelle la plus importante de ce prompt. Sans elle, les équipes écrivent « la base de données est tombée » comme cause racine et s’arrêtent là. Le prompt vous oblige à creuser plus loin : quelle propriété du système a rendu possible la chute de la base de données ? Y avait-il un coupe-circuit ? Aucune alerte sur le pool de connexions ? Un environnement de staging sous-dimensionné qui a masqué la défaillance ? Ce sont les facteurs contributifs — et c’est ce que vous corrigez réellement.
Le langage sans blâme est une contrainte, pas une préférence de ton. Le prompt indique explicitement au modèle de neutraliser le langage accusateur s’il apparaît dans les notes brutes que vous collez. C’est important car les fils Slack bruts et les canaux d’incident sont remplis de phrases comme « Jean a poussé sans relire le runbook » qui, reformulée systémiquement, devient « la checklist de déploiement n’incluait pas d’étape de relecture obligatoire du runbook pour ce type de service ». La correction est la même, mais une version construit une culture où les ingénieurs signalent les quasi-accidents, et l’autre non.
Le tableau des actions est formaté avec le Rôle (pas le nom) et une Échéance délibérément. Les post-mortems qui attribuent des actions à des personnes nommées échouent lorsque cette personne quitte l’équipe. Assigner à un rôle rend l’action durable malgré les changements d’organisation. Les échéances imposent une priorisation ; sans elles, les tâches P1 traînent dans un backlog pendant des mois.
Exemple de résultat
Voici le résultat produit par ce prompt lorsqu’on lui donne un incident d’épuisement du pool de connexions en entrée :
Incident Post-Mortem : Panne de l’API de Paiement — Épuisement du Pool de Connexions
Date : 2026-05-14 Sévérité : P0 Durée : 1 heure 23 minutes Statut : Résolu
Résumé exécutif
Un déploiement de Payment API v4.17.2 a introduit une requête base de données qui ne libérait pas ses connexions en condition de timeout, épuisant le pool de connexions PostgreSQL en 34 minutes après le déploiement. Les requêtes de paiement ont échoué pour 100 % des utilisateurs entre 14:02 et 15:25 UTC. Aucune donnée de paiement n’a été perdue ; toutes les transactions en vol ont été annulées proprement.
Cause racine
La nouvelle requête getPaymentMethodDetails() ouvrait une transaction base de données mais n’incluait pas de gestionnaire de timeout pour le chemin d’E/S réseau. Sous une latence élevée de l’API du fournisseur de paiement, la transaction bloquait indéfiniment sans libérer sa connexion. Sans limite de connexion par type de requête et sans coupe-circuit, le pool s’est épuisé complètement en 34 minutes.
Facteurs contributifs
- Le pipeline CI n’avait pas d’analyse statique pour vérifier le cycle de vie des connexions dans les requêtes base de données
- L’environnement de staging utilise un pool de connexions 10 fois plus petit que la production, empêchant ce mode de défaillance d’apparaître lors des tests de charge à l’échelle du staging
- Le processus d’approbation du rollback nécessitait la signature d’un second ingénieur, ajoutant 14 minutes au temps de récupération sans escalade définie si l’approbateur était indisponible
- Aucune alerte n’existait pour une disponibilité du pool de connexions inférieure à 20 % — la première alerte n’a été déclenchée qu’après l’épuisement total du pool
Actions (extrait)
- P0 : Ajouter une alerte de marge du pool de connexions à 30 % de capacité restante — Infrastructure d’astreinte — 2026-05-21
- P0 : Définir une approbation de rollback accélérée pour les incidents P0 (5 min max) — Responsable Engineering — 2026-05-21
- P1 : Ajouter une règle de lint dans le CI pour les transactions base de données sans garde-fou — Plateforme Backend — 2026-05-28
Tirer le meilleur parti du prompt
La qualité du résultat est directement proportionnelle à la qualité de vos données brutes. Un fil Slack avec des horodatages et des détails techniques produira une chronologie plus précise qu’un résumé en paragraphe. Si vos notes d’incident sont légères, ajoutez une deuxième passe : après le résultat initial du post-mortem, enchaînez avec « Maintenant, auditez les actions — certaines sont-elles vagues ou non attribuables ? Si oui, reformulez-les pour qu’elles soient spécifiques. » Le modèle les resserrera.
Pour les types d’incidents récurrents (pannes liées au déploiement, problèmes de base de données, défaillances d’API tierces), vous pouvez constituer une bibliothèque d’anciens post-mortems et demander au modèle de comparer le nouveau : « Voici trois post-mortems précédents de notre service de paiement. Quels facteurs contributifs apparaissent dans ce nouvel incident et qui étaient également présents dans les précédents ? » Cela fait ressortir des schémas systémiques que les post-mortems individuels manquent.
Claude Opus 4.7 produit les réécritures sans blâme les plus nuancées — il détecte de manière fiable les subtils langages accusateurs que GPT-4o laisse parfois passer. Pour des incidents simples avec des notes brutes propres, Claude Sonnet 4.6 ou GPT-4o sont rapides et suffisants.