Un postmortem de incidente es una breve revisión por escrito de una caída: qué pasó, cómo afectó a los usuarios, por qué ocurrió y qué vas a cambiar para que no se repita. Un postmortem sin culpables (blameless) se centra en los sistemas y los procesos, no en quién se equivocó. La plantilla básica tiene seis partes: resumen, impacto, cronología, causa raíz, qué fue bien y qué fue mal, y acciones con responsables y fechas.
A continuación verás cuándo escribir uno, los principios que lo mantienen útil, una plantilla completa para copiar, un ejemplo rellenado y cómo convertirlo en un resumen para clientes.
Cuándo escribir un postmortem
No todos los pequeños fallos necesitan un documento. Define criterios claros para no tener que decidirlo bajo presión. Los más habituales:
Los clientes no pudieron usar una función clave, como el pago, el inicio de sesión o la API, durante más de unos minutos.
Se perdieron, se corrompieron o quedaron expuestos datos.
El incidente consumió una parte importante de tu error budget mensual.
Los clientes o un cliente informaron del problema antes que la monitorización.
Ya había ocurrido antes un incidente del mismo tipo.
Escríbelo en pocos días laborables, mientras los recuerdos y los logs siguen frescos. Un postmortem escrito tres semanas después es, sobre todo, conjeturas.
Principios de un postmortem sin culpables
Un postmortem sin culpables parte de que todo el mundo actuó de forma razonable con la información que tenía en ese momento. Si una persona pudo tumbar la web con un solo comando, el problema es que un solo comando podía tumbar la web. Buscar culpables hace que la gente oculte detalles, y los detalles son justo lo que necesitas.
Describe acciones, no personas. «La importación se lanzó en horas punta» en lugar de «Anna lanzó la importación en mal momento».
Pregunta «cómo», no «quién». ¿Cómo permitió esto el sistema? ¿Cómo nos enteramos? ¿Cómo podríamos habernos enterado antes?
Busca varias causas. Los incidentes rara vez tienen una única causa raíz. Lo normal es que un desencadenante se encuentre con una debilidad que una salvaguarda ausente no detectó.
Usa hechos y marcas de tiempo. Los datos de monitorización, los logs y el historial del chat ganan a la memoria.
Mantén corta la lista de acciones. Dos o tres cambios que se hacen valen más que diez que no se hacen.
La plantilla de postmortem
Cópiala en tu wiki, repositorio o herramienta de documentos. Cada encabezado indica qué debe ir en él.
# Postmortem: [título breve]
Fecha del incidente: [AAAA-MM-DD]
Autor(es): [nombres]
Estado: [borrador / en revisión / final]
Gravedad: [p. ej., SEV1 / SEV2 / SEV3]
## Resumen
[Dos o tres frases: qué falló, durante cuánto tiempo y cómo se resolvió.]
## Impacto
– Servicios y componentes afectados:
– Duración (del inicio a la recuperación):
– Usuarios o clientes afectados:
– Impacto en el negocio (pedidos, registros, SLA):
– Comunicación con clientes (página de estado, emails, tickets):
## Detección
– ¿Cómo se detectó el incidente? (monitor, cliente, miembro del equipo)
– Tiempo desde el inicio hasta la alerta:
– Tiempo desde la alerta hasta el reconocimiento:
## Cronología
[Todas las horas en una misma zona horaria. Una línea por evento.]
HH:MM evento
HH:MM evento
## Causa raíz y factores contribuyentes
– Desencadenante:
– Causa de fondo:
– Por qué no lo detectaron las salvaguardas:
## Resolución
[Qué se hizo para restablecer el servicio y quién lo hizo (rol, no culpa).]
## Qué fue bien
–
## Qué fue mal
–
## Dónde tuvimos suerte
–
## Acciones
| Acción | Tipo (prevenir / detectar / responder) | Responsable | Fecha límite | Ticket |
|——–|—————————————-|————-|————–|——–|
| | | | | |
## Resumen para clientes
[Versión breve para la página de estado o el email al cliente.]
La sección «Dónde tuvimos suerte» es fácil de saltarse y, a menudo, la más valiosa. Recoge los casi-accidentes: el incidente ocurrió de noche, la copia de seguridad se había hecho una hora antes, la única persona que conocía el sistema casualmente estaba despierta.
Un ejemplo rellenado
Esta es la plantilla aplicada a un incidente ficticio en una tienda online, northwind.shop. Los detalles son inventados a modo de ejemplo, pero la estructura es la que debería tener un postmortem real.
Resumen
De 03:12 a 03:19 CET, el checkout de northwind.shop devolvió 503 Service Unavailable. Una importación nocturna de productos ocupó todos los workers de PHP-FPM, así que se rechazaron las peticiones del checkout. El desarrollador de guardia detuvo la importación y reinició PHP-FPM. Tiempo total de caída: 7 minutos.
Impacto
El checkout y el carrito no estuvieron disponibles durante 7 minutos. Las páginas de producto se sirvieron desde la caché y siguieron funcionando.
Los logs del servidor muestran 23 peticiones de checkout fallidas en ese intervalo (cifra de ejemplo).
La página de estado mostró «Checkout: caída grave» desde las 03:13. No se recibió ningún ticket de soporte.
Cronología
03:00 Empieza la importación nocturna de productos.
03:12 La comprobación de disponibilidad de northwind.shop/checkout devuelve 503.
03:13 Una segunda comprobación confirma el fallo. Se abre un incidente, se avisa al desarrollador de guardia por Telegram y se publican los detalles en el canal de Slack del equipo. La página de estado marca Checkout como caído.
03:15 La persona de guardia lo reconoce en Slack y abre el panel del servidor. La memoria y la CPU están altas en web-01.
03:17 El estado de PHP-FPM muestra todos los workers ocupados con peticiones de la importación. Se detiene la importación.
03:18 Se reinicia PHP-FPM.
03:19 Las comprobaciones vuelven a pasar. Se envía un aviso de recuperación con un tiempo total de caída de 7 minutos.
Causa raíz y factores contribuyentes
Desencadenante: el feed del proveedor era tres veces más grande de lo habitual tras una actualización del catálogo.
Causa de fondo: la importación se ejecuta en el mismo pool de PHP-FPM que la tienda. Las importaciones grandes pueden ocupar todos los workers.
Salvaguarda ausente: la importación no tiene límite de peticiones simultáneas y no había ninguna alerta por saturación de workers.
Si quieres saber por qué los workers agotados se manifiestan precisamente con este error, consulta nuestra guía sobre el error 503 Service Unavailable.
Qué fue bien, qué fue mal y dónde hubo suerte
Bien: la detección tardó un minuto y el reconocimiento, dos. La página de estado se actualizó sin trabajo manual.
Mal: encontrar la causa llevó cuatro minutos porque nada relacionaba la importación con los servidores web.
Suerte: ocurrió a las 03:12, no durante el pico de la tarde.
Acciones
AcciónTipoResponsablePlazoEjecutar la importación en un pool de workers aparte con un límite de concurrenciaPrevenirResponsable de backendEn 2 semanasAlertar cuando la memoria de web-01 se mantenga por encima del 85 tectarOperacionesEsta semanaAñadir un heartbeat que informe cuando termine la importaciónDetectarResponsable de backendEsta semanaAñadir al monitor el runbook de «503 en el checkout»ResponderRotación de guardiasEsta semana
Publicar un resumen para clientes
El postmortem interno es para el equipo. Los clientes necesitan una versión más breve y sin nombres de servidores: qué pasó, cuánto duró, si sus datos están a salvo y qué vas a cambiar. Publícala en tu página de estado y enlázala desde cualquier email sobre el incidente o actualización para clientes. En Uptimecheck redactas la revisión del incidente en el propio incidente, junto a su cronología, y puedes elegir mostrarla bajo el incidente en tu página de estado.
Checkout no disponible, de 03:12 a 03:19 CET
Entre las 03:12 y las 03:19 CET, los clientes no pudieron completar
compras en northwind.shop. La navegación por los productos no se vio
afectada y no se perdió ningún pedido ni dato de pago.
La causa fue una actualización programada de productos que consumió
más capacidad del servidor de lo previsto. La detuvimos y el checkout
se recuperó a las 03:19.
Vamos a trasladar estas actualizaciones a una capacidad separada para
que no puedan volver a afectar al checkout, y hemos añadido avisos más
tempranos para este tipo de carga.
Mantén un tono factual y unos compromisos concretos. «Nos tomamos muy en serio la fiabilidad» no dice nada; «las importaciones ahora se ejecutan con capacidad separada» sí dice algo. Nuestra guía sobre cómo crear una página de estado trata con más detalle la redacción de las actualizaciones de incidentes.
También ayuda saber cuánta gente se dio cuenta. Uptimecheck incluye analítica de la página de estado en cada página de estado, con visitas por día y por país, referente y dispositivo de los últimos 30 días, para que puedas añadir al postmortem cuántas personas consultaron la página el día del incidente. Junto con la cronología del incidente, eso te da el inicio, la alerta, el reconocimiento, la recuperación y el alcance sin tener que rebuscar en los logs. Los incidentes de webs incluyen además la respuesta fallida, con una captura de pantalla o un traceroute, lo que es un buen punto de partida para las secciones de detección y causa raíz.
Seguimiento de las acciones
Un postmortem sin acciones terminadas es un relato, no una solución. Trata las acciones como cualquier otro trabajo:
Crea un ticket para cada acción en el mismo gestor que ya usa el equipo y enlázalo desde el postmortem.
Asigna a cada una un único responsable y una fecha límite.
Etiqueta las acciones por tipo: prevenir, detectar o responder. Si todas las acciones son «tener más cuidado», la revisión no estaba terminada.
Revisa las acciones pendientes de los postmortems en una reunión periódica, por ejemplo cada dos semanas.
Marca el postmortem como final solo cuando todas las acciones estén hechas o se hayan descartado expresamente con un motivo.
Con el tiempo, los propios postmortems se convierten en datos. Cuenta cuántos incidentes detectó la monitorización y cuántos los clientes, y sigue los tiempos de detección y respuesta de un incidente a otro. Nuestro artículo sobre MTTR, MTTA y MTBF explica cómo calcularlos.
Cómo llevar la reunión de revisión
En los incidentes más grandes, ayuda una reunión de 30 a 45 minutos. Comparte el borrador con antelación, deja que la persona que dirigió la respuesta repase la cronología y dedica la mayor parte del tiempo a los factores contribuyentes y a las acciones. Un moderador neutral que no haya trabajado en el incidente mantiene la conversación sin culpables y dentro del tiempo. Termina confirmando los responsables y las fechas de cada acción.
Consigue automáticamente las marcas de tiempo para tu próximo postmortem. Prueba Uptimecheck gratis durante 14 días, sin tarjeta de crédito.