Pasé seis meses diseñando un sistema de alertas que funcionaba exactamente como lo había especificado y volvió menos seguro lo que monitoreaba. Los técnicos que convivían con él me enseñaron por qué — sobre todo silenciándolo.
Esta no es una historia de mal diseño que se arregla. Es una historia sobre cómo el patrón más común en monitoreo industrial — umbrales, notificaciones, pageos — tiene un modo de falla que se ve como funcionar bien. La cura para “no sabemos cuándo algo anda mal” son las alertas. La enfermedad que aparece después es demasiadas alertas. Y la cura para esa enfermedad, si la dejás avanzar, es silenciar. Una vez silenciado, el sistema vuelve al punto de partida — solo que ahora nadie le confía nada.
Quiero recorrer tres fases del problema, porque el patrón es el mismo ya sea que estés diseñando para refrigeración industrial, telemetría de producción, logística de fleets o tableros de riesgo en plataformas de trading. El sustrato cambia; el modo de falla, no.
Fase 1 — alertas básicas, caos básico
El sistema de alertas más simple también es el más fácil de shippear. Definís umbrales. Los conectás a un canal de notificación. Cantás victoria.
Esto fue lo que ayudé a construir para una plataforma de monitoreo industrial que servía a cuatro clientes empresariales — el más grande operaba una fleet de unidades de refrigeración distribuidas en múltiples sitios. La primera versión hacía tres cosas: dispararse al cruzar un umbral, mandar un mail, paginar a alguien si el cruce persistía. Era correcto. Era completo. Hacía exactamente lo que decía el spec.
Tres semanas después del rollout amplio, notamos dos cosas. Primero, las alertas se disparaban — mucho. Algunos sensores generaban decenas de alertas por día, la mayoría por condiciones transitorias que se autoresolvían antes de que alguien pudiera revisar. Segundo, los técnicos habían encontrado cómo silenciarlas. Algunos usaban el mute interno. Otros armaban filtros en el mail. Unos pocos pidieron salir directamente de las listas de notificación, citando “ruido.”
Los nombres por defecto no ayudaban. El sistema autogeneraba nombres como Alerta 1, Alerta 2, Alerta 17. Cuando un cliente llegaba a tener ochenta alertas configuradas en seis sitios, la vista de management se volvía incomprensible — una pared de Alerta 43 sin forma de triarlas por relevancia.
Lo que nadie decía, porque no tenían el lenguaje para decirlo: los técnicos no estaban silenciando alertas malas. Estaban silenciando el sistema que no sabía distinguir alertas buenas de malas. La cura no era menos alertas. La cura era un sistema que pudiera distinguir.
El costo invisible — el silencio no es señal
Esta es la parte del diseño de alertas que más me costó entender. Una vez que un técnico silencia una alerta, perdés la capacidad de diagnóstico más importante de todo el sistema: la capacidad de distinguir silenciado porque no servía de silenciado porque el operador se rindió.
Desde el punto de vista de la plataforma, los dos casos se ven idénticos — un flag que pasa de “on” a “off.” Desde el punto de vista del operador, son decisiones radicalmente distintas. La primera es higiene de información. La segunda es renuncia profesional.
Esto importa porque las fallas que sí deberían paginar a alguien — las que no son transitorias, las que indican un problema real en desarrollo — ocurren contra un fondo de alertas silenciadas que el sistema ya no puede distinguir de silencio sano. Un sistema de alertas silenciado es peor que no tener alertas, porque al menos un sistema ausente hace visible su inutilidad. Un sistema silenciado se hace pasar por funcionar.
Esto es lo que quiero decir con la cura es la enfermedad. La cura (las alertas) y la enfermedad (el silenciamiento) comparten interruptor, y una vez que el interruptor se baja, el sistema se miente a sí mismo de manera estructural.
Fase 2 — alertas refinadas
La segunda versión hizo cuatro cosas distintas, cada una respuesta directa a un modo de falla de la fase anterior.
Los nombres salieron del contexto, no de un contador. En vez de Alerta 17, una alerta configurada para monitorear la temperatura del compresor en una unidad de refrigeración pasó a llamarse Temperatura compresor > 75°C, Sitio B, Unidad 12 — autogenerada desde la configuración. Esto no es nombrar como detalle de UI; es nombrar como primitivo de triage. Cuando la vista de management se vuelve ordenable y escaneable, la proliferación de alertas deja de ser una crisis de jerarquía de información.
Las alertas de conectividad aprendieron a discriminar. “Desconectado” antes significaba una sola cosa — un heartbeat ausente. La Fase 2 distinguió un corte de luz (el edificio se quedó sin energía, el device está bien cuando vuelva) de una pérdida de señal (el device está prendido pero no nos puede alcanzar, generalmente un problema de router) de una micro-caída (el heartbeat saltó un ciclo y volvió, que casi siempre no es nada). Tres categorías, tres políticas de notificación, una reducción enorme de ruido. Fue la palanca más grande de todo el rediseño.
La flexibilidad de horarios dejó de ser feature avanzada. La primera versión asumía pageo 24/7. Las operaciones reales tienen horario laboral. Algunas tienen turno noche; otras no. Algunas tratan los fines de semana como sin impacto al cliente y pasan a resumen diario en lugar de pageo inmediato. Construir esto como default — no como tier pago, no como setting avanzado — hizo que el workflow real del operador dejara de pelearse con el sistema.
Las notificaciones encontraron al operador donde ya estaba. La primera versión era mail por defecto. Los operadores casi sin excepción preferían WhatsApp — no porque WhatsApp sea técnicamente superior, sino porque ya lo tenían abierto, ya lo monitoreaban, ya respondían más rápido por ahí. Conveniencia técnica y preferencia del usuario no son lo mismo. Preguntar en qué canal vive el operador es una pregunta más confiable que preguntar qué canal preferiría en teoría.
El patrón en las cuatro decisiones es el mismo: respetar el contexto que ya existía. El sistema de alertas no aterriza en el vacío. Se suma a un workflow que ya estaba ahí, y su trabajo es agregar señal sin agregar fricción.
Fase 3 — qué significaría una alerta inteligente
No tengo evidencia para esta fase, porque el rediseño de Fase 2 fue donde terminó mi paso por el proyecto. Pero todas las conversaciones que tuve con operadores convergían en la misma pregunta: ¿el sistema puede aprender lo que yo ya sé?
Lo que el operador ya sabe — lo que actualmente está bloqueado en su cabeza — es qué patrones transitorios son normales en su sitio. Un compresor dado en un sitio dado tiene una curva de calentamiento diaria que ocasionalmente cruza un umbral por treinta segundos y después se acomoda. El técnico lo sabe. El sistema de alertas, no. El técnico silencia la alerta o aprende a ignorarla. El sistema perdió la pericia del técnico.
Las alertas de Fase 3 aprenden los patrones locales. Autocalibran umbrales según el historial de cada sitio. Predicen contra el patrón, no contra el absoluto. Routean basándose en lo que no está pasando — el dropout silencioso — tanto como en lo que sí.
Es la dirección a la que cada sistema de monitoreo en el que trabajé desde entonces tuvo que ir, sin importar el sustrato. Refrigeración industrial. Riesgo en plataformas de trading. Telemetría de producción. El patrón es invariante: las alertas que distinguen raro de anormal son las únicas que sobreviven al contacto con un operador real.
El principio, finalmente
La mayoría de los sistemas de alertas que revisé desde aquel proyecto tienen la estructura de la Fase 1. Los specifica un equipo que quiere saber cuándo algo anda mal. Los construyen ingenieros que conectan umbrales a canales. Se rollean a operadores que, en cuestión de semanas, encuentran cómo silenciarlos.
La razón por la que el patrón se repite es que el problema de diseño no es la alerta. El problema de diseño es la asimetría entre la mirada del sistema sobre la alerta (una fila en una base de datos, un payload en una cola) y la mirada del operador (una pequeña interrupción que tiene que valer su costo). Cuando el sistema no puede modelar el costo-de-interrupción del operador, da igual qué tan precisos sean los umbrales — el operador es el cuello de botella, y va a routear alrededor de cualquier sistema que no respete su función de costo.
La cura para “no sabemos cuándo algo anda mal” no son más alertas. Es un sistema de alertas que se gane suficiente confianza como para no ser silenciado. La confianza se construye una alerta no disparada a la vez.