Gere uma post-mortem completa e sem culpados a partir de uma linha do tempo bruta de incidentes
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 escritas sob pressão de tempo — ou dias depois que a adrenalina passa — tendem a ser superficiais. Elas perdem fatores contribuintes, ignoram os padrões sistêmicos que tornaram o incidente possível ou, silenciosamente, atribuem culpa por meio da escolha de palavras. Este prompt força a estrutura que torna as post-mortems realmente úteis: linguagem sem culpados, causa raiz separada de fatores contribuintes e itens de ação específicos o suficiente para serem encerrados.
O prompt
Copie-o na íntegra. Substitua cada campo entre colchetes pelos detalhes reais do seu incidente antes de executá-lo.
Atue como um engenheiro sênior de confiabilidade de sites (SRE) com vasta experiência em escrever post-mortems sem culpados para sistemas de alto tráfego.
Contexto:
O seguinte incidente foi resolvido. Você recebeu uma linha do tempo bruta dos eventos, os fatores contribuintes identificados durante a retrospectiva e as etapas de remediação que a equipe executou.
Detalhes do incidente:
- Serviço afetado: [NOME DO SERVIÇO, ex.: "Payment API", "Serviço de Autenticação de Usuário"]
- Severidade: [P0/P1/P2]
- Duração: [HORA DE INÍCIO] a [HORA DE TÉRMINO] ([DURAÇÃO TOTAL])
- Impacto ao cliente: [DESCREVA O IMPACTO, ex.: "100% das solicitações de checkout falharam por 47 minutos"]
- Linha do tempo bruta / notas: [COLE AQUI SUAS NOTAS DO INCIDENTE, THREAD DO SLACK OU ENTREGAS DO RUNBOOK]
Tarefa:
Escreva um documento de post-mortem completo, profissional e sem culpados, seguindo os princípios da cultura de post-mortem do Google SRE. O documento deve identificar falhas do sistema e lacunas de processo — nunca culpa individual.
Restrições:
- Use linguagem sem culpados em todo o texto. Diga "o pipeline de deployment não tinha uma barreira para X", não "o engenheiro esqueceu de verificar X"
- Diferencie entre causa raiz (a falha fundamental do sistema ou processo) e fatores contribuintes (condições que permitiram que a causa raiz tivesse impacto)
- Itens de ação devem ser específicos, atribuíveis e mensuráveis — não vagos ("melhorar monitoramento")
- Não encha a linha do tempo. Inclua apenas eventos que afetaram a trajetória do incidente
- Se as notas brutas contiverem linguagem de culpabilização, neutralize-a na post-mortem
Formato de saída:
**Post-Mortem do Incidente: [TÍTULO DO INCIDENTE]**
**Data:** [DATA] **Severidade:** [P0/P1/P2] **Duração:** [X horas Y minutos] **Status:** Resolvido
**Resumo Executivo**
[2-3 frases: o que falhou, por quanto tempo, impacto ao cliente e status]
**Linha do Tempo** (todos os horários em [FUSO HORÁRIO])
[Lista cronológica: horário → o que aconteceu / quem detectou / qual ação foi tomada]
**Causa Raiz**
[Um parágrafo identificando a falha fundamental do sistema ou processo. Sem linguagem de culpabilização.]
**Fatores Contribuintes**
[Lista com marcadores: cada fator que permitiu que a causa raiz gerasse impacto]
**Impacto**
[Quantificado: % de usuários afetados, solicitações com falha, exposição de receita se conhecida, violação de SLA se aplicável]
**O Que Deu Certo**
[Avaliação honesta: velocidade de detecção, comunicação, sucesso do rollback, etc.]
**O Que Deu Errado**
[Avaliação honesta e sem culpados: caminhos de escalonamento lentos, runbooks ausentes, responsabilidades pouco claras, etc.]
**Itens de Ação**
| Prioridade | Ação | Responsável (Função) | Prazo |
|---|---|---|---|
| P0 | [Ação específica] | [Função, não nome] | [DATA] |
**Lições Aprendidas**
[2-3 frases: a lição sistêmica que este incidente ensina, enquadrada para tomada de decisões futuras]Por que cada seção está ali
A distinção entre causa raiz e fatores contribuintes é a decisão estrutural mais importante deste prompt. Sem ela, as equipes escrevem "o banco de dados caiu" como causa raiz e pronto. O prompt força você a ir mais fundo: que propriedade do sistema tornou possível "o banco de dados cair"? Não havia um circuit breaker? Nenhum alerta de pool de conexões? Um ambiente de staging subdimensionado que mascarou a falha? Esses são os fatores contribuintes — e são eles que você realmente corrige.
Linguagem sem culpados é uma restrição, não uma preferência de tom. O prompt instrui explicitamente o modelo a neutralizar linguagem de culpabilização se ela aparecer nas notas brutas que você cola. Isso é importante porque threads brutas do Slack e canais de incidente estão cheios de afirmações como "João fez push sem revisar o runbook" — que, reformulada sistemicamente, vira "a checklist de deployment não incluía uma etapa obrigatória de revisão de runbook para este tipo de serviço." A correção é a mesma, mas uma versão constrói uma cultura onde engenheiros relatam quase-acidentes e a outra não.
A tabela de itens de ação é formatada com Função (não nome) e Prazo de forma deliberada. Post-mortems que atribuem itens de ação a indivíduos nomeados falham quando essa pessoa sai da equipe. Atribuir a uma função torna o item durável através de mudanças organizacionais. Prazos forçam priorização; sem eles, itens P1 ficam num backlog por meses.
Exemplo de saída
Aqui está a saída que este prompt produz quando recebe como entrada um incidente de exaustão de pool de conexões:
Post-Mortem do Incidente: Indisponibilidade da Payment API — Exaustão do Pool de Conexões
Data: 2026-05-14 Severidade: P0 Duração: 1 hora e 23 minutos Status: Resolvido
Resumo Executivo
Um deployment da Payment API v4.17.2 introduziu uma consulta ao banco de dados que não liberava conexões sob condições de timeout, exaurindo o pool de conexões PostgreSQL em 34 minutos após o deploy. As solicitações de checkout falharam para 100% dos usuários entre 14h02 e 15h25 UTC. Nenhum dado de pagamento foi perdido; todas as transações em andamento foram revertidas de forma limpa.
Causa Raiz
A nova consulta getPaymentMethodDetails() abria uma transação de banco de dados mas não incluía um handler de timeout para o caminho de I/O de rede. Sob latência elevada da API do provedor de pagamento, a transação bloqueava indefinidamente sem liberar sua conexão. Sem limite de conexão por tipo de consulta e sem circuit breaker, o pool se exauriu completamente em 34 minutos.
Fatores Contribuintes
- O pipeline de CI não tinha uma verificação de análise estática para gerenciamento de ciclo de vida de conexões em consultas ao banco de dados
- O ambiente de staging usa um pool de conexões 10× menor que o de produção, impedindo que esse modo de falha aparecesse em testes de carga em escala de staging
- O processo de aprovação de rollback exigia a aprovação de um segundo engenheiro, adicionando 14 minutos ao tempo de recuperação sem uma escalada definida caso o aprovador estivesse indisponível
- Não existia alerta para disponibilidade de pool de conexões abaixo de 20% — o primeiro alerta foi disparado apenas quando o pool já estava exaurido
Itens de Ação (excerto)
- P0: Adicionar alerta de margem de pool de conexões a 30% restantes — Infraestrutura de Plantão — 2026-05-21
- P0: Definir aprovação de rollback de caminho rápido para incidentes P0 (máx. 5 min) — Gerente de Engenharia — 2026-05-21
- P1: Adicionar regra de linting ao CI para transações de banco de dados sem proteção — Plataforma Backend — 2026-05-28
Obtendo o máximo do prompt
A qualidade da saída escala diretamente com a qualidade da sua entrada bruta. Uma thread do Slack com timestamps e detalhes técnicos produzirá uma linha do tempo mais precisa do que um resumo em parágrafo. Se suas notas de incidente forem superficiais, adicione uma segunda passada: após a saída inicial da post-mortem, complemente com "Agora audite os itens de ação — algum deles é vago ou não atribuível? Se sim, reescreva-os para serem específicos." O modelo os ajustará.
Para tipos recorrentes de incidente (indisponibilidades relacionadas a deploy, problemas de banco de dados, falhas de API de terceiros), você pode construir uma biblioteca de post-mortems anteriores e pedir ao modelo que compare a nova: "Aqui estão três post-mortems anteriores do nosso serviço de pagamento. Quais fatores contribuintes aparecem neste novo incidente que também apareceram nos anteriores?" Isso traz à tona padrões sistêmicos que post-mortems individuais perdem.
O Claude Opus 4.7 produz as reescritas sem culpados mais matizadas — ele captura de forma confiável linguagem sutil de culpabilização que o GPT-4o às vezes deixa passar. Para incidentes diretos com notas brutas limpas, o Claude Sonnet 4.6 ou o GPT-4o são rápidos e suficientes.