El equipo que aprendió a ignorar las alertas

El día que nadie miró el canal de Slack

Era un martes por la tarde cuando Marta, CTO de una startup de pagos en Madrid con 35 ingenieros, se dio cuenta de que tenían un problema serio. El canal #alertas-prod de Slack tenía 1.247 mensajes sin leer. No de la semana. Del día.

Nadie los había leído. Nadie los iba a leer. Y lo peor: todos sabían que eso estaba pasando y nadie lo consideraba un problema.

Ese momento de reconocimiento —que un canal crítico para la operación del negocio se había convertido en ruido de fondo— es lo que los ingenieros llaman fatiga de alertas. Y es más común de lo que nadie quiere admitir.

Qué es exactamente la fatiga de alertas

La fatiga de alertas (o alert fatigue) ocurre cuando el volumen de notificaciones es tan alto que el equipo desarrolla una respuesta de desensibilización: deja de prestar atención a las alertas, o las descarta de forma automática sin leerlas.

No es una debilidad humana. Es una respuesta adaptativa completamente racional ante un entorno de sobrecarga de información.

El problema es que esa adaptación tiene consecuencias graves:

Los incidentes reales pasan desapercibidos hasta que un cliente llama para quejarse
El equipo pierde la confianza en el sistema de monitorización
La cultura de guardia se deteriora: nadie quiere hacer on-call si sabe que va a recibir 300 alertas inútiles cada noche
El tiempo de respuesta ante incidentes aumenta: cuando todo es urgente, nada lo es

El diagnóstico del equipo de Marta

Cuando Marta hizo un análisis retrospectivo de tres meses de alertas, encontró un patrón inquietante:

| Categoría | Volumen | Acción tomada | |-----------|---------|---------------| | CPU > 80% durante 5 min | 2.847 | 0 (se autorresuelve) | | Latencia p99 > 500ms | 1.234 | 3 investigaciones | | Pod reiniciado | 967 | 12 investigaciones | | Certificado expira en 30d | 4 (mismo cert) | 1 renovación | | Deploy completado | 543 | 0 (informativas) | | Incidentes reales | 8 | 8 |

De casi 6.000 alertas en tres meses, solo 8 requerían acción. El ratio señal/ruido era del 0.13%.

El equipo había aprendido, inconscientemente, a filtrar mentalmente el 99.87% de las alertas. El problema es que esa habilidad no es perfecta: en dos ocasiones, una alerta real se perdió entre el ruido y tardaron más de dos horas en detectar el incidente.

Por qué los sistemas de alertas se convierten en generadores de ruido

Marta no empezó queriendo montar un generador de spam. Llegó ahí de forma incremental:

1. El síndrome de "mejor alertar por si acaso" Cada vez que surgía un incidente, el equipo añadía una nueva alerta para "nunca más perderse eso". Sin proceso de revisión, sin métricas de valor.

2. Los umbrales por defecto de las herramientas Prometheus, Datadog y Grafana vienen con dashboards y alertas por defecto muy conservadores. Nadie los revisó durante el setup inicial.

3. La falta de propiedad clara ¿Quién es el dueño de limpiar alertas obsoletas? En la mayoría de equipos: nadie. Las alertas se añaden pero nunca se eliminan.

4. La escalabilidad de los microservicios Cuando pasaron de 5 servicios a 40, el número de alertas no creció linealmente: creció exponencialmente.

Cómo lo resolvieron (y qué aprendieron)

El equipo de Marta implementó lo que internamente llamaron la "dieta de alertas":

Fase 1: Auditoría brutal (1 semana)

Para cada alerta, una pregunta: ¿Hemos tomado alguna acción en los últimos 30 días a raíz de esta alerta? Si la respuesta era no, la alerta quedaba en cuarentena.

Resultado: 73% de las alertas eliminadas o silenciadas en la primera semana.

Fase 2: Priorización por impacto de negocio

Redefinieron los umbrales basándose en impacto real:

Crítico: Afecta directamente a transacciones o usuarios activos
Alto: Degradación perceptible del servicio
Medio: Comportamiento anómalo sin impacto inmediato (para revisión en horario laboral)
Informativo: Todo lo demás (log, no alerta)

Fase 3: Deduplicación de grupos

En vez de recibir 50 alertas "Pod reiniciado" cuando un deployment sale mal, configuraron ventanas de agrupación de 5 minutos. Un evento, una notificación.

Los resultados a los 60 días

Alertas diarias: de 1.247 a 23
Tiempo de respuesta promedio: de 47 minutos a 8 minutos
Incidentes detectados por el propio equipo (no por clientes): del 62% al 94%
Satisfacción del equipo de guardia: "por fin volvemos a confiar en las alertas"

El coste real de la fatiga de alertas

Antes de llegar a ese punto, Marta calculó lo que les había costado la fatiga de alertas:

2 incidentes tardíos detectados por clientes antes que por el equipo: 4 horas de ingeniería + impacto reputacional
Rotación de equipo: dos ingenieros senior mencionaron el caos de on-call como razón para buscar empleo
Reuniones de postmortem que analizaban síntomas en vez de causas raíz porque nadie tenía claro qué alertas habían disparado

Un estudio de IBM Security estima que el coste promedio de un incidente detectado tarde (> 1 hora) es de 4.200 EUR en un equipo de 10 ingenieros. Con dos incidentes tardíos al mes, hablamos de 100.000 EUR al año solo en coste de respuesta.

La solución de fondo: filtrado inteligente con IA

La dieta de alertas de Marta funcionó para poner orden, pero tenía un problema: era un proceso manual que requería mantenimiento constante. A los seis meses, los umbrales volvían a estar desactualizados.

La siguiente evolución fue introducir una capa de IA que evaluara automáticamente cada alerta antes de enviarla al equipo:

Correlación contextual: ¿Esta alerta de CPU está correlacionada con un deploy reciente?
Historial de la señal: ¿Esta alerta se ha autorresuelto las últimas 20 veces?
Criticidad del servicio: ¿El servicio afectado es de cara al cliente o es un worker interno?
Scoring dinámico: Un score 0-100 que resume toda esa información en una sola métrica accionable

Solo las alertas con score > 70 llegan al canal de Slack. El resto se registran para análisis pero no interrumpen al equipo.

Conclusión

La fatiga de alertas no es un problema técnico que se resuelve añadiendo más monitorización. Es un problema de diseño del sistema de observabilidad.

Los síntomas son claros: canales con miles de mensajes sin leer, equipos que apagan las notificaciones del móvil de guardia, ingenieros que buscan trabajo porque "el on-call es insoportable".

La solución tampoco es técnicamente compleja: se trata de filtrar agresivamente, priorizar por impacto de negocio y usar IA para hacer ese filtrado de forma continua y automática.

El equipo de Marta tardó tres meses en volver a confiar en sus alertas. Con las herramientas adecuadas, ese proceso se puede comprimir a días.

¿Tu equipo tiene más de 100 alertas al día? Conecta centinelAI gratis y en 10 minutos verás cuánto ruido puedes eliminar.