Guía de inglés para developers
Escribir un Postmortem de Incidente en Inglés: Lenguaje Sin Culpas
21 de octubre de 2026
Describir una caída de forma factual, sin convertir la línea de tiempo en una lista de quién la regó, es una convención de escritura específica con su propio vocabulario. Así se escribe cada sección en inglés.
Puntos clave
- Un postmortem 'blameless' describe qué pasó a nivel de sistema, no quién lo causó personalmente: 'the deploy script did not validate the config,' no 'Juan forgot to check the config.'
- Todo postmortem necesita cinco secciones: resumen, línea de tiempo, impacto, causa raíz y tareas de seguimiento.
- 'Mitigated' significa que el impacto se detuvo. 'Resolved' significa que la causa raíz ya está arreglada de verdad. No son la misma palabra.
- Los nombres están bien en una línea de tiempo cuando describen una acción ('Maria deployed the hotfix at 14:32 UTC'), no cuando presentan a la persona como la causa de la falla.
- Las tareas de seguimiento necesitan un responsable y una fecha, igual que cualquier otra tarea, o desaparecen calladamente después de la reunión.
'Blameless' es una convención de escritura, no solo una actitud
Blameless is a writing convention, not just a feeling
La mayoría de las empresas de tecnología angloparlantes escriben postmortems de incidentes usando una convención específica llamada 'blameless': el reporte describe qué pasó y por qué a nivel de sistema, y evita deliberadamente presentar a una sola persona como la causa.
Esto no es solo una gentileza cultural, es un conjunto específico de patrones de frases. El mismo hecho: un deploy que se saltó una validación de configuración, se puede escribir de una forma que suene a acusación o de una forma que suene a descripción de sistema. Los equipos angloparlantes esperan la segunda, y escribirla bien es una habilidad que a la mayoría de los developers nunca les enseñaron explícitamente.
Esta guía cubre la estructura que necesita todo postmortem, la forma exacta de redactarlo sin culpas y el vocabulario para describir severidad, mitigación y resolución.
Las cinco secciones que necesita todo postmortem
The five sections every postmortem needs
Distintas empresas usan distintas plantillas, pero casi todas se reducen a estas cinco secciones. Escríbelas en este orden.
Resumen
Una o dos frases: qué se rompió, por cuánto tiempo y a quién afectó.
Línea de tiempo
Eventos con marca de tiempo desde la detección hasta la resolución completa, en el orden en que pasaron.
Impacto
Quién y qué se vio afectado: usuarios, requests, ingresos, datos, en números concretos si los tienes.
Causa raíz
Qué fue lo que realmente disparó el incidente a nivel de sistema, no quién lo disparó.
Tareas de seguimiento
Cambios específicos, con responsable y fecha, que hacen que este tipo de incidente sea menos probable o menos grave.
Frases que culpan vs. frases sin culpa
Blaming phrasing vs. blameless phrasing
Esta es la habilidad central. El mismo hecho se puede escribir de dos formas: una nombra a una persona como la causa, la otra nombra el hueco del sistema que permitió que pasara. Solo la segunda es el estándar en un postmortem en inglés.
Juan forgot to check the config before deploying.
The deploy process did not include a config validation step.
The on-call engineer missed the alert.
The alert was not routed to a channel that was actively monitored at that hour.
Whoever wrote this migration didn't test it properly.
The migration was not tested against a production-sized dataset before release.
The reviewer should have caught this in the PR.
The code review process did not include a check for this class of error.
This happened because someone pushed straight to main.
A direct push to main bypassed the CI checks that would normally catch this.
The team ignored the warning signs last week.
The warning signs from last week were not escalated into an actionable alert.
Escribir la línea de tiempo
Writing the timeline
Las entradas de la línea de tiempo siguen un patrón fijo: una marca de tiempo en UTC, seguida de una frase corta y factual en pasado. Mantén un evento por línea. Aquí un ejemplo corto:
Fíjate en el vocabulario: 'fired,' 'acknowledged,' 'rolled back,' 'mitigating,' 'resolved.' Son los verbos estándar para una línea de tiempo de incidente en inglés.
Describir la severidad y el impacto
Describing severity and impact
La mayoría de las empresas usan una escala de Sev1 a Sev4 (a veces P1 a P4). Acompaña la etiqueta con una descripción en inglés simple del impacto real, no solo el número.
| Sev1 / P1 | Caída total o una falla crítica de cara al cliente. |
| Sev2 / P2 | Degradación significativa pero parcial: afecta a algunos usuarios o a parte de la funcionalidad. |
| Sev3 / P3 | Problema menor con impacto limitado, a menudo detectado antes de que la mayoría de los usuarios lo note. |
| Sev4 / P4 | Problema cosmético o de impacto muy bajo, normalmente se arregla en un ciclo de trabajo normal. |
Preguntas frecuentes
¿Qué significa 'blameless postmortem'?
Un 'blameless postmortem' es la convención estándar en la mayoría de las empresas de tecnología angloparlantes para revisar un incidente: describes qué pasó y por qué a nivel de sistema, no quién cometió el error personalmente. La idea es que las personas actúan de forma razonable dada la información y las herramientas que tenían, así que la solución es mejorar el sistema (tests, alertas, procesos, documentación), no señalar a una persona.
¿Puedo mencionar igual quién hizo qué en un postmortem?
Sí, los nombres están bien en la línea de tiempo cuando describen una acción, no una acusación: 'Maria deployed the hotfix at 14:32 UTC' es neutral y útil. Lo que se evita es presentar la acción de alguien como la causa de la falla: el punto es que el sistema permitió que esa acción causara una caída, lo cual es un problema de proceso, no de personas.
¿Cómo describo la severidad de un incidente en inglés?
La mayoría de las empresas usan una escala de Sev1 a Sev4 (o P1 a P4): Sev1 significa una caída total o una falla crítica de cara al cliente; Sev2 es una degradación importante pero parcial; Sev3 y Sev4 son problemas menores con impacto limitado. En el texto, acompaña la etiqueta de severidad con una descripción simple: 'This was a Sev1: the checkout flow was fully unavailable for 23 minutes.'
¿Cuál es la diferencia entre 'mitigated' y 'resolved' en un reporte de incidente?
'Mitigated' significa que el impacto inmediato se detuvo, normalmente mediante un rollback, un feature flag o una solución temporal, pero la causa de fondo puede seguir presente. 'Resolved' significa que la causa raíz ya se arregló de verdad. Una línea de tiempo suele tener ambas: 'Mitigated at 14:40 UTC by rolling back the deploy. Resolved at 16:15 UTC once the config validation fix was merged.'
Artículos relacionados
¿Listo para practicar tu inglés en el trabajo?
Lingua-e tiene ejercicios interactivos basados en conversaciones reales de developers: standups, code reviews, retrospectivas y más. Practica hasta que salga solo.
Prueba Lingua-e gratis
Escrito por
Roxana LafuenteFundadora de Lingua-e
Roxana Lafuente es ingeniera de software con más de 8 años de experiencia. Al comienzo de su carrera, aunque ya había aprobado el First Certificate in English, se bloqueaba cada vez que tenía que hablar en el standup diario. Era un problema que nadie estaba resolviendo. Después de más de 2.000 standups, descubrió qué es lo que realmente construye la fluidez: practicar situaciones que se parecen a tu trabajo real. Creó Lingua-e para que otros developers no tuvieran que tomar el camino largo para sentirse seguros trabajando en un entorno de desarrollo internacional.