Genera un post-mortem completo y sin culpas a partir de una cronología de incidente en bruto
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.
Los post-mortem escritos bajo presión de tiempo — o días después de que la adrenalina se disipa — suelen ser superficiales. Omiten factores contribuyentes, ignoran los patrones sistémicos que hicieron posible el incidente, o asignan culpas de manera sutil a través de la elección de palabras. Este prompt fuerza la estructura que hace que los post-mortem sean realmente útiles: lenguaje sin culpas, causa raíz separada de factores contribuyentes, y elementos accionables lo suficientemente específicos para cerrar.
El prompt
Copia esto completo. Reemplaza cada campo entre corchetes con los detalles reales de tu incidente antes de ejecutarlo.
Actúa como un ingeniero senior de confiabilidad del sitio (SRE) con amplia experiencia en la redacción de post-mortem sin culpas para sistemas de alto tráfico.
Contexto:
El siguiente incidente ha sido resuelto. Se te ha proporcionado una cronología en bruto de eventos, los factores contribuyentes identificados durante la retrospectiva y los pasos de remediación que el equipo tomó.
Detalles del incidente:
- Servicio afectado: [NOMBRE DEL SERVICIO, ej., "API de Pagos", "Servicio de Autenticación de Usuarios"]
- Severidad: [P0/P1/P2]
- Duración: [HORA INICIO] a [HORA FIN] ([DURACIÓN TOTAL])
- Impacto en clientes: [DESCRIBE EL IMPACTO, ej., "El 100% de las solicitudes de pago fallaron durante 47 minutos"]
- Cronología / Notas en bruto: [PEGA TUS NOTAS DEL INCIDENTE, HILO DE SLACK O ANOTACIONES DEL RUNBOOK AQUÍ]
Tarea:
Escribe un documento post-mortem profesional y completo, sin culpas, siguiendo los principios de la cultura de post-mortem de SRE de Google. El documento debe identificar fallas del sistema y brechas en los procesos — nunca culpas individuales.
Restricciones:
- Usa lenguaje sin culpas en todo momento. Di "el pipeline de despliegue no tenía un gate para X", no "el ingeniero olvidó revisar X"
- Distingue entre causa raíz (la falla fundamental del sistema o proceso) y factores contribuyentes (condiciones que permitieron que la causa raíz tuviera impacto)
- Los elementos accionables deben ser específicos, asignables y medibles — no vagos ("mejorar el monitoreo")
- No alargues la cronología. Incluye solo los eventos que afectaron la trayectoria del incidente
- Si las notas en bruto contienen lenguaje culpabilizador, neutralízalo en el post-mortem
Formato de salida:
**Incident Post-Mortem: [TÍTULO DEL INCIDENTE]**
**Fecha:** [FECHA] **Severidad:** [P0/P1/P2] **Duración:** [X horas Y minutos] **Estado:** Resuelto
**Resumen ejecutivo**
[2-3 oraciones: qué falló, durante cuánto tiempo, impacto en clientes y estado]
**Cronología** (todas las horas en [ZONA HORARIA])
[Lista cronológica con viñetas: hora → qué sucedió / quién lo detectó / qué acción se tomó]
**Causa raíz**
[Párrafo único identificando la falla fundamental del sistema o proceso. Sin lenguaje de culpa.]
**Factores contribuyentes**
[Lista con viñetas: cada factor que permitió que la causa raíz tuviera impacto]
**Impacto**
[Cuantificado: % de usuarios afectados, solicitudes fallidas, exposición de ingresos si se conoce, violación de SLA si aplica]
**Qué salió bien**
[Evaluación honesta: velocidad de detección, comunicación, éxito del rollback, etc.]
**Qué salió mal**
[Evaluación honesta y sin culpas: rutas de escalada lentas, runbooks faltantes, propiedad poco clara, etc.]
**Elementos accionables**
| Prioridad | Acción | Rol Responsable | Fecha Límite |
|---|---|---|---|
| P0 | [Acción específica] | [Rol, no nombre] | [FECHA] |
**Lecciones aprendidas**
[2-3 oraciones: la lección sistémica que este incidente enseña, enmarcada para la toma de decisiones futura]Por qué está cada sección
La distinción entre causa raíz y factores contribuyentes es la decisión estructural más importante en este prompt. Sin ella, los equipos escriben "la base de datos se cayó" como causa raíz y lo dan por terminado. El prompt te obliga a ir más profundo: ¿qué propiedad del sistema hizo posible que "la base de datos se cayera"? ¿No había un circuit breaker? ¿Sin alerta de pool de conexiones? ¿Un entorno de staging sobredimensionado que enmascaró la falla? Esos son los factores contribuyentes — y son lo que realmente corriges.
El lenguaje sin culpas es una restricción, no una preferencia de tono. El prompt le dice explícitamente al modelo que neutralice el lenguaje culpabilizador si aparece en las notas en bruto que pegas. Esto importa porque los hilos de Slack y canales de incidentes están llenos de afirmaciones como "John hizo push sin revisar el runbook" — que, replanteado sistémicamente, se convierte en "la lista de verificación de despliegue no incluía un paso obligatorio de revisión del runbook para este tipo de servicio". La solución es la misma, pero una versión construye una cultura donde los ingenieros reportan los cuasi accidentes y la otra no.
La tabla de elementos accionables está formateada con Rol (no nombre) y Fecha Límite deliberadamente. Los post-mortem que asignan elementos accionables a individuos nombrados fallan cuando esa persona deja el equipo. Asignar a un rol hace que el elemento sea duradero a través de cambios organizativos. Las fechas límite fuerzan la priorización; sin ellas, los elementos P1 se quedan meses en el backlog.
Ejemplo de salida
Esta es la salida que produce el prompt cuando se le proporciona un incidente de agotamiento del pool de conexiones:
Incident Post-Mortem: Caída de API de Pagos — Agotamiento del Pool de Conexiones
Fecha: 2026-05-14 Severidad: P0 Duración: 1 hora 23 minutos Estado: Resuelto
Resumen ejecutivo
Un despliegue de Payment API v4.17.2 introdujo una consulta a la base de datos que no liberaba conexiones en condiciones de timeout, agotando el pool de conexiones de PostgreSQL en 34 minutos desde el despliegue. Las solicitudes de pago fallaron para el 100% de los usuarios entre las 14:02 y las 15:25 UTC. No se perdió ningún dato de pago; todas las transacciones en vuelo se revirtieron limpiamente.
Causa raíz
La nueva consulta getPaymentMethodDetails() abrió una transacción de base de datos pero no incluyó un manejador de timeout para la ruta de I/O de red. Bajo latencia elevada de la API del proveedor de pagos, la transacción se bloqueaba indefinidamente sin liberar su conexión. Sin un límite de conexiones por tipo de consulta y sin circuit breaker, el pool se agotó completamente en 34 minutos.
Factores contribuyentes
- El pipeline de CI no tenía un análisis estático para la gestión del ciclo de vida de conexiones en consultas a la base de datos
- El entorno de staging usa un pool de conexiones 10 veces más pequeño que producción, lo que impidió que este modo de falla apareciera en las pruebas de carga a escala de staging
- El proceso de aprobación de rollback requería la firma de un segundo ingeniero, añadiendo 14 minutos al tiempo de recuperación sin una escalada definida si el aprobador no estaba disponible
- No existía una alerta para la disponibilidad del pool de conexiones por debajo del 20% — la primera alerta se disparó solo después de que el pool ya estaba agotado
Elementos accionables (extracto)
- P0: Añadir alerta de margen del pool de conexiones al 30% restante — Infraestructura en Guardia — 2026-05-21
- P0: Definir aprobación de rollback rápido para incidentes P0 (máx. 5 min) — Manager de Ingeniería — 2026-05-21
- P1: Añadir regla de linting en CI para transacciones de base de datos sin protección — Plataforma Backend — 2026-05-28
Cómo sacarle el máximo partido al prompt
La calidad de la salida escala directamente con la calidad de tu entrada en bruto. Un hilo de Slack con marcas de tiempo y detalles técnicos producirá una cronología más precisa que un resumen en un párrafo. Si tus notas del incidente son escasas, añade una segunda pasada: después de la salida inicial del post-mortem, continúa con "Ahora audita los elementos accionables — ¿hay alguno que sea vago o no asignable? Si es así, reescríbelos para que sean específicos". El modelo los ajustará.
Para tipos de incidentes recurrentes (caídas relacionadas con despliegues, problemas de base de datos, fallos de API de terceros), puedes construir una biblioteca de post-mortem anteriores y pedirle al modelo que compare el nuevo: "Aquí tienes tres post-mortem anteriores de nuestro servicio de pagos. ¿Qué factores contribuyentes aparecen en este nuevo incidente que también aparecieron en los anteriores?" Esto saca a la luz patrones sistémicos que los post-mortem individuales pasan por alto.
Claude Opus 4.7 produce las reescrituras sin culpas más matizadas — detecta de manera confiable el lenguaje sutil de culpa que GPT-4o a veces deja pasar. Para incidentes sencillos con notas en bruto limpias, Claude Sonnet 4.6 o GPT-4o son rápidos y suficientes.