Plantilla de notificación de caída

Una notificación de caída informa a los clientes de que un servicio del que dependen está interrumpido, qué está afectado y qué está haciendo tu equipo al respecto. Suele tomar dos formas: un aviso en tu página de estado, que se actualiza a medida que avanza el incidente, y un correo a los clientes afectados.

Es un mensaje público. Los detalles internos, como el cambio sospechoso, quién está de guardia o la hipótesis que el equipo está comprobando, se quedan en el canal del incidente y en el informe de incidente. La notificación dice solo lo que los clientes necesitan para decidir qué hacer a continuación.

A estos mismos mensajes se les suele llamar comunicación de incidentes: el conjunto de actualizaciones que produce un incidente, desde el primer reconocimiento hasta la resolución.

Las páginas de estado llevan un incidente por cuatro etapas. Cada una le dice algo distinto a los clientes, y cada actualización reemplaza a la anterior.

No todos los incidentes pasan por las cuatro. Una reversión rápida puede ir directamente de Investigando a Monitoreando. Sáltate una etapa antes que publicar una actualización que no dice nada nuevo.

El estado del servicio indica cuánto del servicio pueden usar los clientes. Coincide con el estado del componente en tu página de estado, para que el aviso y la página digan lo mismo.

• Degradado. El servicio funciona, pero mal: respuestas lentas, errores intermitentes, procesamiento con retraso.
• Interrupción parcial. Una parte del servicio no funciona para algunos usuarios: una funcionalidad, una región o un grupo de cuentas.
• No disponible. El servicio no se puede usar en absoluto.

Describe el impacto con el estado del servicio, no con tu severidad interna. La severidad es la forma en que tu equipo decide con qué urgencia responder y a quién alertar. Para un cliente, "SEV-2" no significa nada, y puede confundir: un incidente crítico para una cuenta grande puede ser una interrupción parcial para todos los demás. El estado del servicio describe lo que los clientes realmente experimentan.

El estado del servicio puede cambiar durante un incidente. Si una interrupción parcial se extiende, actualiza el aviso a No disponible en lugar de dejar el estado original.

Publica el primer aviso en cuanto se confirme el impacto en los clientes, antes de conocer la causa. Para eso existe Investigando. Los clientes que ven errores junto a una página de estado toda en verde suponen que no lo sabes, y abren tickets de soporte para decírtelo.

Actualiza el aviso cada vez que cambie el estado del incidente o el estado del servicio. Durante una investigación larga, publica una actualización aunque no haya cambiado nada, para que la página no parezca abandonada.

Envía un correo a los clientes afectados cuando empieza el incidente y cuando se resuelve. Si también conviene enviarlo en Identificado y Monitoreando depende de cuánto dure el incidente; en uno corto, la página de estado cubre los pasos intermedios.

Aviso en la página de estado

Un aviso mantiene el mismo título durante toda su vida. Describe el síntoma, no la causa: "Tasas de error elevadas en la API", no "Pool de conexiones de la base de datos agotado". Omite los nombres de componentes si la lista puede cambiar, y omite la severidad.

Junto al título van el estado del incidente, el estado del servicio, los componentes afectados y cuándo empezó el impacto. Los clientes usan la hora de inicio para relacionar el incidente con los problemas que vieron, así que indica siempre la zona horaria. La plantilla completa la hora actual en la tuya.

La actualización en sí ocupa una o dos frases: qué está afectado y qué estás haciendo. No especules sobre la causa ni prometas una hora de resolución que no puedas cumplir.

Correo a clientes

El asunto transmite el mensaje a quien no abre el correo: [estado del incidente] título del aviso (afecta a componentes) → estado del servicio. Por ejemplo, "[Investigando] Tasas de error elevadas en la API (afecta a API) → Interrupción parcial". Los clientes pueden filtrar por él, y un correo posterior con "[Resuelto]", sin el estado del servicio, cierra el hilo.

El cuerpo repite palabra por palabra la actualización de la página de estado, para que los datos sean los mismos en todos los canales, y enlaza a la página de estado para seguir las novedades. Cuando el incidente se resuelve, el enlace se sustituye por una invitación a responder con preguntas.

Los siguientes ejemplos continúan el incidente INC-2026-017 que se usa en las plantillas de informe de incidente y de postmortem. Alrededor del 18% de las solicitudes a la API fallaron durante 28 minutos, mientras que los paneles y la página de estado siguieron funcionando: una interrupción parcial.

Título del aviso: Tasas de error elevadas en la API Componentes afectados: API Hora de inicio: 2026-09-03 14:03 UTC

El mismo incidente como Degradado

Si las consultas solo hubieran ralentizado la API en lugar de hacer fallar solicitudes, el estado del servicio sería Degradado, y la primera actualización diría:

Estamos investigando reportes de problemas que afectan a algunas funcionalidades. Los usuarios pueden experimentar ligeros retrasos o errores intermitentes.

Correo a clientes

Asunto: [Investigando] Tasas de error elevadas en la API (afecta a API) → Interrupción parcial

Hola, Alex:

Estamos investigando una interrupción parcial. Algunas funcionalidades no están disponibles actualmente para algunos usuarios.

Puedes seguir el progreso en nuestra página de estado: status.example.com

Lamentamos las molestias.

El equipo de Example

El aviso y el correo se escriben en minutos, para los clientes, mientras el incidente sigue en curso. El postmortem llega después y da la explicación. El informe de incidente es el registro interno detrás de los tres.

• Empieza por el impacto, no por la causa. Los clientes necesitan saber qué no pueden hacer. La causa puede esperar al postmortem.
• Usa un lenguaje sencillo. Escribe "algunos usuarios no pueden iniciar sesión", no "tasas elevadas de 5xx en el servicio de autenticación".
• No especules. Di que has identificado la causa solo cuando la hayas identificado. Corregir en público una suposición equivocada cuesta más confianza que esperar.
• Describe el impacto con el estado del servicio y deja las etiquetas de severidad para uso interno. Degradado, interrupción parcial o no disponible les dice a los clientes lo que están experimentando; los niveles SEV no.
• Mantén los mismos datos en todos los canales. La página de estado, el correo y lo que soporte les dice a los clientes deben coincidir.
• No prometas una hora de resolución que no puedas cumplir. Una estimación incumplida hace más daño que ninguna.
• Cierra cada incidente. Un aviso que se queda horas en Monitoreando hace que los clientes se pregunten si ya terminó.

¿Qué debe incluir una plantilla de comunicación de incidentes?

Cada actualización debe decir qué está afectado, en qué medida (degradado, interrupción parcial o no disponible) y qué está haciendo tu equipo, además de cuándo empezó el problema. Limita cada actualización a una o dos frases, y deja la causa y los detalles internos para el postmortem.

¿Con qué frecuencia hay que informar a los clientes durante una interrupción?

Cada vez que cambie el estado del incidente o el estado del servicio. Durante una investigación larga, publica también a intervalos regulares, por ejemplo cada 30 o 60 minutos, aunque no haya cambiado nada, para que los clientes sepan que el incidente no se ha olvidado.

¿Cuál es la diferencia entre rendimiento degradado e interrupción parcial?

Con un rendimiento degradado, el servicio sigue funcionando para todos, pero con lentitud o con errores intermitentes. En una interrupción parcial, una parte del servicio no funciona en absoluto para algunos usuarios, como una funcionalidad, una región o un grupo de cuentas.

¿Hay que disculparse en una notificación de caída?

Sí, en el correo a clientes. Una frase como "Lamentamos las molestias" reconoce el impacto sin convertir el mensaje en un comunicado. Las actualizaciones de la página de estado pueden limitarse a los hechos.

Decide antes del próximo incidente quién publica el aviso, quién envía el correo y qué clientes lo reciben. Escribe el texto con antelación, como hace esta plantilla, para que la primera actualización salga en minutos y no después de un debate sobre la redacción. Registra esas decisiones en tu plan de respuesta a incidentes.

Con constancia, las notificaciones de interrupción reducen los tickets de soporte del tipo "¿está caído?" y mantienen informados a los clientes durante los incidentes que no puedes evitar.

Más sobre comunicación de incidentes en el blog de StatusPal (en inglés):

• All About Incident Communication: por qué las plantillas escritas de antemano mantienen los mensajes rápidos y coherentes, y los pasos de primer contacto, actualización de estado y resolución que sigue esta plantilla.
• How To Create an Incident Communication Plan: a quién informar, por qué canales, y por qué las actualizaciones regulares importan incluso cuando no ha cambiado nada.
• Key Learnings from the Facebook Status Page: qué sale mal cuando una página de estado muestra "operativo" durante una interrupción, o no indica cuándo empezó el incidente.