Alertas de caída web: cómo configurarlas por email, push y Slack

Recibir una alerta de caída web en menos de 2 minutos marca la diferencia entre resolver el problema antes de que el cliente lo note y encontrarte con un WhatsApp de pánico. En este artículo explicamos cómo configurar alertas efectivas por email, WhatsApp y otros canales, y qué información debe incluir una buena alerta para que puedas actuar de inmediato.

Por qué el canal de alerta importa tanto como la velocidad

Una alerta que llega en 1 minuto a un canal que nadie revisa es tan inútil como no tener alerta. El canal de notificación tiene que adaptarse a cómo trabaja tu equipo en la práctica.

La pregunta clave es: ¿dónde mirará primero la persona responsable cuando haya una incidencia a las 3 de la tarde un martes? ¿Y a las 10 de la noche un viernes? Las respuestas pueden ser distintas, y un buen sistema de alertas cubre ambas.

Alertas por email: el canal base

El email es el canal de alerta más universal. Todas las herramientas de monitorización lo soportan, deja rastro escrito y permite incluir mucho detalle en la notificación.

Para que las alertas por email sean efectivas:

• Asunto claro y urgente — "⚠️ CAÍDA: cliente.com lleva 3 min sin responder" es mucho más accionable que "Notificación de monitorización"
• Datos concretos en el cuerpo — URL afectada, código de error HTTP, hora exacta de detección, tiempo acumulado de caída
• Link directo a la web — para verificar el estado con un clic desde el móvil
• Separar alertas de caída de alertas de recuperación — recibir el "ya está online" es tan importante como recibir el "ha caído"

El problema del email es que muchos equipos no lo revisan en tiempo real, especialmente fuera de horario laboral. Para incidencias críticas, necesitas un canal complementario.

Alertas por notificación push (móvil)

Las notificaciones push en el móvil son el canal más efectivo para alertas urgentes fuera de horario. Interrumpen, son visibles aunque el teléfono esté boca abajo y no requieren instalar nada adicional si la herramienta tiene app móvil.

Son especialmente útiles para:

• Alertas fuera de horario laboral
• Incidencias que requieren acción inmediata (caídas totales, errores SSL críticos)
• El responsable técnico de guardia

Alertas por Slack o Teams

Si tu equipo trabaja con Slack o Microsoft Teams, integrar las alertas de monitorización en un canal específico es muy eficiente. Todas las alertas en un mismo lugar, visible para todo el equipo, con contexto y trazabilidad.

La configuración recomendada:

• Canal #alertas-clientes para todas las notificaciones de monitorización
• Menciones @channel o @aquí solo para caídas críticas
• Notificaciones de recuperación también en el mismo canal, para cerrar el loop

Alertas por SMS

El SMS es el canal con mayor tasa de apertura (98%) y el que funciona incluso sin conexión a internet. Para incidencias críticas en clientes importantes, el SMS asegura que la alerta llega.

El uso recomendado es como canal de escalado: si la alerta por email o push no genera respuesta en X minutos, escala a SMS. Así evitas SMS innecesarios para incidencias menores y reservas el canal para las realmente críticas.

Qué información debe incluir una alerta de caída web

Una alerta útil debe permitirte entender la situación y empezar a actuar sin tener que abrir ningún otro panel. Información mínima imprescindible:

• URL afectada
• Tipo de incidencia (caída total, tiempo de respuesta alto, error SSL, código HTTP de error)
• Hora exacta de detección
• Duración acumulada de la incidencia
• Código de error HTTP si aplica (500, 503, 404...)
• Link para verificar el estado en tiempo real

Con esa información, el responsable puede en segundos: confirmar si la caída es real, identificar si es un error del servidor o del hosting, y decidir si hay que actuar inmediatamente o esperar unos minutos más.

Cómo evitar la fatiga de alertas

Si recibes demasiadas alertas, dejas de hacerles caso — y el día que importa no reaccionas. La fatiga de alertas es un problema real.

Para evitarla:

• Configura un mínimo de confirmaciones antes de alertar — una caída de 30 segundos puede ser un falso positivo. Espera 1-2 minutos de confirmación antes de enviar la alerta.
• Agrupa alertas del mismo sitio — si una web está caída, no necesitas una alerta cada minuto. Una al detectar la caída y otra al recuperarse.
• Diferencia severidades — una respuesta lenta (TTFB > 1s) no merece la misma alerta que una caída total. Configura canales distintos por severidad.
• Revisa y limpia periódicamente — si un sitio tiene muchos falsos positivos, investiga la causa y ajusta los umbrales.

Protocolo de actuación cuando llega la alerta

Tener un protocolo escrito hace que la respuesta sea más rápida y menos estresante:

1. Verificar desde otra red que la caída es real (no un falso positivo de tu conexión)
2. Intentar acceder al panel del hosting para ver alertas activas
3. Si el hosting tiene problemas reportados, notificar al cliente con un mensaje breve: "Estamos viendo una incidencia en tu hosting, ya están trabajando en ello"
4. Si no hay alertas del hosting, revisar el último cambio hecho en la web (actualización de plugin, cambio de DNS, modificación de código)
5. Escalar al técnico responsable si no se resuelve en 10-15 minutos

Para un protocolo completo, lee nuestra guía sobre cómo detectar caídas web antes que tu cliente.

La diferencia entre detectar y resolver

Un sistema de alertas bien configurado garantiza la detección rápida. La resolución depende de las causas — puede ser inmediata o llevar horas. Lo que el cliente necesita saber es que estás al tanto desde el primer minuto.

Una status page complementa perfectamente el sistema de alertas: mientras resuelves la incidencia, el cliente puede ver en tiempo real que está siendo atendida, sin necesidad de que nadie le llame.