Cómo configurar alertas de downtime efectivas (sin fatiga de alertas)

Que te avisen cuando la web cae es crítico. Que te avisen 47 veces del mismo problema por 5 canales distintos, no. La diferencia entre un sistema de alertas bien configurado y uno ruidoso es la diferencia entre un equipo que responde bien y otro que acaba ignorando las alertas por completo.

El problema de la fatiga de alertas

La fatiga de alertas es real, peligrosa y más común de lo que parece. Cuando hay demasiadas alertas, el equipo empieza a ignorarlas — incluso las críticas. Más del 30 % de las alertas en muchas organizaciones se ignoran o no se actúa sobre ellas. No es un problema de personas; es de configuración.

El objetivo es simple: cada alerta debe ser accionable, y cada problema accionable debe generar una alerta. Todo lo demás es ruido.

Elegir canales de alerta

Cada canal tiene su papel. Así puedes pensar en ellos:

Slack / Discord / Teams

Mejor para: conciencia del equipo, alertas no críticas, coordinación durante Incidents.

Las plataformas de mensajería son ideales para mantener al equipo informado, pero no para despertar a alguien a las 3 AM. Los mensajes se entierran, las notificaciones se silencian y los canales se saturan.

Usa Slack para:

• Avisos de rendimiento degradado
• Notificaciones de recuperación (para saber que ya está resuelto)
• Resúmenes diarios o semanales de uptime
• Coordinación durante caídas activas

Email

Mejor para: registro, escalado, actualizaciones a stakeholders.

El email es permanente y buscable: ideal para auditoría y comunicación con stakeholders. Pero es lento para urgencias: casi nadie revisa el correo en tiempo real.

Usa email para:

• Informes y resúmenes de Incidents
• Alertas de incumplimiento de SLA a dirección
• Informes semanales de uptime
• Avisos no urgentes de degradación

Webhooks

Mejor para: automatización, flujos a medida, integración con tu toolchain.

Los webhooks son el canal más flexible. Cuando un Monitor detecta un problema, un webhook puede:

• Crear un ticket en Jira o Linear
• Abrir un Incident en PagerDuty
• Lanzar un script de remediación
• Publicar en un dashboard interno
• Actualizar un Status Page automáticamente

Usa webhooks para:

• Plataformas de gestión de Incidents
• Respuestas automatizadas
• Enrutado de notificaciones personalizado
• Herramientas internas

SMS / llamadas

Mejor para: alertas críticas que deben despertarte a las 3 AM.

Reserva SMS y llamadas para caídas graves de producción que requieren intervención humana inmediata. Si usas este canal para menos, la gente lo silencia y falla cuando más lo necesitas.

Buenas prácticas de configuración de alertas

1. Confirma antes de alertar

Un solo check fallido no es una caída. Parpadeos de red, picos de carga y errores transitorios son habituales. Configura los Monitors para exigir 2–3 fallos consecutivos antes de disparar la alerta.

Esto elimina la mayoría de falsos positivos sin retrasar mucho la detección real. Con intervalo de 30 s y 2 fallos seguidos, sabrás de una caída real en unos 60 s — suficiente para casi cualquier situación.

2. Clasifica por niveles

No todos los servicios merecen la misma intensidad de alerta. Crea niveles:

Nivel 1 — Crítico (ingreso / producto principal)

• Intervalo: 15–30 s
• Canales: Slack + Webhook (p. ej. PagerDuty) + SMS
• Confirmación: 2 fallos
• Ejemplos: aplicación principal, API, autenticación, pagos

Nivel 2 — Importante (servicios de apoyo)

• Intervalo: 60 s
• Canales: Slack + Email
• Confirmación: 3 fallos
• Ejemplos: documentación, blog, panel admin, herramientas internas

Nivel 3 — Opcional (no crítico)

• Intervalo: 5 min
• Canales: Email
• Confirmación: 3 fallos
• Ejemplos: staging, previews, micrositios de bajo tráfico

3. Umbrales de tiempo de respuesta

No alertes solo por caídas totales. Configura alertas por degradación:

• Advertencia: tiempo de respuesta > 2× tu media habitual
• Crítico: tiempo de respuesta > 5× tu media habitual

Una ralentización progresiva suele preceder una caída total. Detectarla pronto te da margen para investigar y evitar el apagón.

4. Agrupa alertas relacionadas

Si la aplicación principal cae, probablemente fallen API, webhooks y CDN a la vez. No necesitas cinco cadenas de alertas para un solo Incident.

Usa agrupación o dependencias en tu herramienta de monitoring. Si api.example.com y app.example.com caen a la vez, una alerta basta.

5. Incluye contexto en las alertas

Una alerta que dice «Monitor caído» ayuda poco. Mejor:

CRÍTICO: api.example.com DOWN3 checks fallidos seguidos desde US-East, EU-West, AP-SoutheastÚltimo código: 503Tiempo de respuesta: timeout (30 s)Duración hasta ahora: 2 minStatus Page: https://status.example.com

Los buenos mensajes reducen el tiempo hasta el diagnóstico: nombre del Monitor, ubicación, motivo del fallo, duración y enlaces útiles.

6. Define rutas de escalado

Si el primer respondedor no reconoce la alerta en 5–10 minutos, escala:

1. Inmediato: ingeniero de guardia vía Slack + webhook
2. 5 min: mismo contacto vía SMS
3. 15 min: responsable de ingeniería por teléfono
4. 30 min: dirección de ingeniería

El escalado evita que los problemas críticos se pierdan si alguien está en reunión o durmiendo.

7. Envía notificaciones de recuperación

Cuando un Monitor se recupera, notifica por los mismos canales que recibieron la alerta. Así:

• El equipo sabe que está resuelto
• Tienes la duración total del downtime
• Cierras el ciclo del Incident
• Evitas investigar algo que ya está arreglado

Errores a evitar

Alertar todos los entornos por igual: no uses alertas de producción para staging o desarrollo. Si staging está caído, suele ser intencionado.

Demasiados canales por evento: elige 2–3 canales máximo por nivel. Si cada fallo va a Slack, email, SMS, Discord y webhook, generas ruido, no cobertura.

Sin ventanas de mantenimiento: si despliegas cada martes, suprime alertas en esa ventana. El downtime planificado no es un Incident.

Ignorar alertas de recuperación: si solo avisas cuando algo falla, tienes que comprobar manualmente si ya está bien. Activa siempre las notificaciones de recuperación.

Conclusión

Unas alertas efectivas se miden por la relación señal/ruido. Cada alerta debe significar «algo está roto y alguien debe actuar». Si el equipo ignora las alertas, el problema no es la disciplina — es la configuración.

Empieza por lo básico: Monitors en servicios críticos, confirmación antes de alertar, niveles adecuados y canales correctos. Ajusta con el tiempo según lo que funcione.

Configura alertas inteligentes en minutos. Empieza gratis — email, Slack y webhooks incluidos en todos los planes.