Alertas de frontend y un bot de triaje asistido por IA

El problema

Los abandonos silenciosos en los traspasos a terceros se descubrían días después a través de atención al cliente. Las alertas se basaban en umbrales y hacían mucho ruido, así que la gente había aprendido a ignorarlas.

El enfoque

• Referencias relativas, no umbrales estáticos. El servicio de alertas ejecuta SQL sobre el almacén de telemetría y compara cada métrica con la misma hora de la semana anterior. Una caída del 20 % significa algo a las 3 de la madrugada en una región y al mediodía en otra, y las oscilaciones del tráfico global dejan de causar falsas alarmas.
• Una alerta que llega con contexto. Cuando salta una alerta, publica una tarjeta de incidente en el chat del equipo. Un proceso en segundo plano reúne entonces los errores recientes del frontend, la versión de configuración activa y los registros de despliegue, y los envía como un prompt estructurado a una API de LLM.
• Un resumen en el hilo. El bot responde con una causa raíz probable, por ejemplo: la conversión de un paso baja en una región, hay un error de puntero nulo en un envoltorio nativo, un cambio de configuración salió 15 minutos antes y un servicio posterior agota el tiempo de espera.

El resultado

El tiempo de detección bajó de horas o días a minutos, el tiempo de mitigación se redujo y las alertas pasaron a ser unas en las que la gente confía. También medí la relación señal-ruido de las alertas (la proporción que corresponde a incidentes reales) y el tiempo medio entre fallos de los módulos de frontend.

Por qué así

Una alerta normal te dice que algo se rompió. Recopilar los datos automáticamente y resumirlos cierra la brecha entre una métrica y una persona que la entiende, que es donde se iba la mayor parte del tiempo de respuesta.