El incidente está cerrado, el canal archivado y el borrador del postmortem ya está escrito — no por quien estuvo de guardia, sino por un modelo que leyó la cronología, la conversación en Slack y los datos de la investigación. Así funciona en incident.io: la plantilla define qué secciones asume la IA y el documento recorre los estados In progress → In review → Completed.
La capa de proveedores debajo se mueve. Jeli llega a su end of life el 22 de diciembre de 2026 y el análisis de incidentes pasa a Post-Incident Reviews dentro de la interfaz web de PagerDuty, todavía en Early Access. FireHydrant fue comprada por Freshworks y se integra en su ServiceOps. La plantilla sobrevive a esa reordenación, y es ella la que decide qué recibe el agente y qué sigue teniendo que escribir una persona.
Los campos se dividen en dos clases
Una parte del postmortem se deduce de los sistemas. La cronología se arma con alertas, despliegues y mensajes del canal. Detection sale del momento en que saltó la alerta. Impact se calcula con métricas y la página de estado. Resolution se ve en la acción que detuvo la degradación. Todo eso lo extrae un modelo sin ayuda humana, y con más cuidado que alguien de guardia a las tres de la madrugada.
La otra parte no se deduce de ninguna parte. Por qué la decisión parecía correcta en ese momento. Qué información tenía la persona cuando la tomó. Qué estuvo a punto de salir peor y no salió.
| Campo | De dónde sale | Quién lo rellena |
|---|---|---|
| Timeline, Detection, Impact, Resolution | alertas, despliegues, métricas, canal | agente |
| Root Causes, Trigger | hipótesis más confirmación en los datos | persona, el agente ayuda |
| Where we got lucky, Lessons Learned | la cabeza de quien participó | solo una persona |
| Action Items | decisión del equipo | solo una persona |
El valor del ingeniero en un postmortem se ha desplazado a la parte baja de esta tabla. Las filas de arriba se automatizan, las de abajo no, y son las que hacen útil el documento medio año después.
Los dos campos que más se pierden
El esquema popular de las «cinco preguntas» — qué pasó, por qué, cuál fue el impacto, cómo respondimos, cómo evitamos que se repita — es tres campos más corto que la plantilla canónica del SRE Book. Dos de ellos conviene recuperarlos.
Trigger separado de Root Causes. El trigger es lo que lo disparó («despliegue de v2.3.0 a las 14:18»). La causa es por qué el sistema era vulnerable a eso («una migración sin índice pasa la revisión porque en este repositorio no se usa la checklist de cambios de base de datos»). Si se funden en un solo campo, queda un corpus donde los incidentes coinciden en el trigger y divergen en el mecanismo. La búsqueda de casos parecidos — con agente o a ojo — empieza a devolver ruido.
Where we got lucky. El único sitio donde quedan registrados los riesgos que esta vez no se dispararon: la tabla estaba casi vacía, el incidente cayó en tráfico diurno, la segunda región se libró por casualidad. No son eventos observables: nadie salvo un participante puede anotarlos. Una línea de aquí suele valer tres puntos de Lessons Learned.
El esqueleto
Date / Authors / Status — metadatos, los pone el sistema
Summary — 3-5 líneas para quien no leyó el canal
Impact — usuarios, minutos, dinero
Root Causes — por qué el sistema era vulnerable
Trigger — qué lo disparó, en campo propio
Resolution — qué detuvo la degradación
Detection — cómo nos enteramos y en cuánto tiempo
Action Items — owner + fecha límite, uno por línea
Lessons Learned
What went well
What went wrong
Where we got lucky — no saltárselo
Timeline — UTC, hechos sin interpretación
Supporting information — gráficas, consultas, enlaces a PRTrece secciones para un SEV3 parecen excesivas: la mitad se cierra con una línea. Un encabezado vacío es más honesto que uno ausente, porque demuestra que la pregunta se hizo.
Cuándo el postmortem es obligatorio
El canon formula los disparadores como umbrales y no como escala de severidad: caída o degradación visible para el usuario por encima de un umbral, pérdida de datos de cualquier tamaño, intervención de guardia como revertir una release o redirigir tráfico, tiempo de resolución por encima de un umbral, fallo del monitoreo. Y el derecho de cualquier stakeholder a pedir un análisis.
La matriz «SEV1/SEV2 obligatorio» es una capa local sobre esa lista, útil cuando la severidad ya está fijada por criterios estrictos y no por la intuición de quien está de guardia. El umbral sobre el error budget consumido entra en la misma matriz: la cifra sale de vuestra política, el canon no la fija.
Dónde mueren los action items
Un punto sin persona responsable y sin fecha no es una acción, es una forma de lamentarse. Un equipo no puede ser el responsable: cuando hay varios, no hay ninguno. Crear tickets automáticamente desde la plantilla elimina el único paso donde los postmortems se cortan, el traslado de las decisiones al gestor de tareas.
Una señal aparte son los análisis repetidos de la misma clase. Tres postmortems con la misma causa significan que el problema no es de conocimiento sino de automatización ausente, y a partir de ahí cuenta como toil.
Lo que no se automatiza
Un modelo reproduce el formato, arma la cronología y propone una redacción de la causa. No crea las condiciones en las que una persona escribe «no entendí la alerta» en lugar de «la alerta no estaba clara».
Lo blameless tiene también una consecuencia de máquina. «Bob borró la tabla» no le da nada a un agente: un nombre no es un rasgo. «El sistema permitió borrar la tabla con un comando y sin confirmación» describe un mecanismo, y con esa descripción se encuentra el siguiente caso igual. Un postmortem que culpa es malo para la cultura e inservible como dato.