Qué información debe acompañar una alerta de servicio caído
Una alerta de servicio caído debe explicar qué comprobación falló, desde dónde, cuándo empezó y quién debe actuar. Añade impacto conocido y un enlace al procedimiento. La frase «servidor no responde» deja demasiadas decisiones pendientes cuando el equipo necesita recuperar una tarea.
Equipo enginerIT· 2 min de lectura
Una alerta de servicio caído debe explicar qué comprobación falló, desde dónde, cuándo empezó y quién debe actuar. Añade impacto conocido y un enlace al procedimiento. La frase «servidor no responde» deja demasiadas decisiones pendientes cuando el equipo necesita recuperar una tarea.
Describe la observación sin inventar la causa
Incluye servicio, entorno y sede, identificador estable y hora con zona horaria. Indica la prueba ejecutada, su resultado esperado y el fallo observado. Distingue respuesta de red, disponibilidad de la aplicación y éxito de una operación funcional: no son evidencias intercambiables.
Añade último éxito conocido, duración y repetición de la comprobación si están disponibles. Si solo un punto de observación detecta la caída, dilo. Evita mensajes que afirmen «base de datos averiada» cuando la única evidencia sea que una página no cargó; esa conclusión puede dirigir mal el diagnóstico.
Da contexto para decidir la prioridad
Relaciona el servicio con la tarea de negocio y los usuarios potencialmente afectados. Separa impacto confirmado de alcance todavía desconocido. Indica si existe una alternativa operativa y dónde se consulta, sin suponer que toda la empresa conoce el procedimiento de contingencia.
Incluye responsable actual, suplente, canal de escalado y caso abierto si existe. Proporciona enlaces a paneles, registros y procedimiento de revisión con permisos adecuados. Prometheus promueve alertas accionables; en este caso significa que el receptor puede decidir su primer paso sin buscar a ciegas qué sistema representa el nombre del aviso.
Haz el mensaje útil sin exponer información
No incrustes contraseñas, documentos de clientes ni respuestas completas que puedan contener datos personales. Resume el error y conserva el detalle en un repositorio autorizado. Revisa qué información llega a correos, móviles o servicios externos al configurar los destinos de notificación.
Prueba el aviso con alguien de guardia que no haya creado la regla: debe localizar el servicio, distinguir hechos de hipótesis y encontrar el siguiente paso. Comprueba también el mensaje de recuperación. Debe permitir relacionar el fin del episodio con el inicio y saber si queda una incidencia pendiente, aunque la comprobación vuelva a responder.
Comprobaciones para cerrar la tarea
- ✓ Servicio, prueba, origen y hora identificados.
- ✓ Impacto confirmado separado de alcance desconocido.
- ✓ Responsable y procedimiento accesibles sin secretos en el aviso.
Fuentes y documentación
- Prometheus: Alerting practices — Recomienda alertar sobre síntomas accionables y comprobar la cadena de monitorización y notificación.
Aplicarlo en tu empresa
Podemos revisar el entorno y acordar qué actuaciones, validaciones y mantenimiento necesitas.
Conocer el servicio relacionado →