El agente que me avisa cuando algo se rompe en mi negocio
Webs caídas, pagos fallidos, formularios rotos. Monté un sistema de avisos para enterarme yo antes que un cliente. Cómo funciona.
Prefiero enterarme yo de que algo se ha roto. No que me lo cuente un cliente.
Suena obvio. Y sin embargo, durante bastante tiempo mi sistema de detección de problemas fue exactamente ese: alguien me escribía diciendo "oye, esto no me funciona".
Monté un vigilante. Te cuento qué vigila, cómo está hecho y los dos errores que cometí montándolo, que son los mismos que va a cometer cualquiera.
El correo que lo empezó todo
"Hola Ruben, llevo dos días intentando escribirte por el formulario de la web y no me llega ninguna confirmación."
Dos días. Y no era el único: el formulario llevaba roto casi una semana. Todo lo que había entrado en esos días se había perdido.
Lo peor de esa semana no fue lo que se perdió. Fue darme cuenta de que si nadie me hubiera escrito, podría haber seguido roto un mes más. Yo no miraba ese formulario. ¿Para qué iba a mirarlo? Funcionaba.
Y esa es la trampa entera. Las cosas que funcionan no se miran. Y por eso, cuando dejan de funcionar, tardas en enterarte justo de las que más importan.
¿Cómo me entero de que algo ha fallado sin mirarlo?
Dándole la vuelta a la pregunta: en vez de comprobar tú si algo va bien, haces que algo te avise cuando va mal.
La diferencia parece semántica y no lo es. Comprobar depende de tu memoria y de tu disciplina, y las dos fallan. Que te avisen no depende de nada tuyo.
Para eso hacen falta dos cosas: una lista de qué es importante y una definición clara de qué significa "está roto" en cada caso.
La segunda parte es la que cuesta. "La web funciona" no se puede vigilar. "La página de precios devuelve una respuesta correcta en menos de cinco segundos" sí se puede vigilar.
Qué vigilo exactamente
Después de un par de iteraciones, la lista se quedó en cinco cosas. Cinco, no cincuenta.
Que las páginas importantes respondan. No todas. Las cuatro o cinco que si se caen me duelen: la portada, las páginas de venta y la de recursos. Cada pocos minutos, una comprobación.
Que los pagos entren. Si pasa un número raro de horas sin ninguna venta en un día laborable normal, quiero saberlo. No porque cada hora sin ventas sea un drama, sino porque un silencio anormalmente largo suele significar que algo del proceso de pago está roto.
Que los formularios lleguen. Un envío de prueba automático cada día, con un texto identificable. Si el envío de prueba no aparece donde tiene que aparecer, aviso. Esto es lo que me habría ahorrado la semana del formulario.
Que los correos automáticos salgan. Los correos de confirmación de compra son lo más crítico que tengo, porque si fallan el cliente ha pagado y no recibe nada. Se comprueba que salieron y que no rebotaron.
Que ciertos datos externos no cambien de golpe. Precios de herramientas que menciono, páginas que sigo, cosas de fuera que si cambian me afectan. Esta parte la lleva Browse AI, que se dedica a mirar páginas web y avisarte cuando cambian. Es una herramienta bastante especializada y hace muy bien ese trabajo concreto; le dediqué un artículo entero en extraer datos de una web con Browse AI.
Cómo está montado
La orquestación la lleva n8n, que es donde viven todos mis flujos. Cada vigilancia es un flujo pequeño con la misma forma: se ejecuta cada tanto, comprueba una cosa, y si el resultado no es el esperado, manda un aviso.
Los avisos van a dos sitios según la gravedad. Los serios (web caída, pagos parados) llegan al móvil directamente. Los menos serios (un dato que ha cambiado, algo que ha tardado más de lo normal) se acumulan en un resumen que recibo una vez al día.
Esa separación es importante y la aprendí a base de sufrir. Si todo va al móvil, en tres días has silenciado el móvil y el sistema entero deja de servir.
Y hay una tercera pieza que añadí después: un vigilante del vigilante. Un aviso que me llega si el sistema de avisos lleva demasiado tiempo sin decir absolutamente nada. Porque un sistema de vigilancia caído se parece muchísimo a un sistema de vigilancia con todo en orden.
El resto de piezas de este tipo, con qué encaja con qué, lo tengo ordenado en automatización y agentes con IA.
Los dos errores que cometí
Error uno: vigilarlo todo.
La primera versión comprobaba treinta cosas. Treinta. Cualquier cosa que se me ocurriera que podía fallar, la metí.
Resultado: entre ocho y diez avisos al día, la mayoría irrelevantes. Una página que tarda un segundo más de lo normal. Un servicio externo con un hipo de treinta segundos. Ruido constante.
En dos semanas dejé de leerlos. Y entonces se rompió algo de verdad y tampoco lo leí, porque estaba entre otros cuatro avisos de nada.
Un sistema de avisos que avisa demasiado es exactamente igual de útil que no tener sistema, con la diferencia de que te ha costado montarlo. Lo bajé de treinta cosas a cinco y desde entonces cada aviso que llega me lo creo.
Error dos: avisos sin contexto.
Los primeros avisos decían cosas como "fallo en el flujo 4". Y yo miraba el móvil, leía "fallo en el flujo 4", y me tocaba abrir el ordenador para saber qué narices era el flujo 4.
Ahora cada aviso dice tres cosas: qué se ha roto en lenguaje normal, desde cuándo, y qué es lo primero que tengo que mirar. Por ejemplo: "la página de precios lleva ocho minutos sin responder, mira si el servidor está arriba".
Parece una tontería y cambia por completo el tiempo que tardo en arreglar algo. La diferencia entre un aviso y un aviso útil es si te dice el siguiente paso.
Lo que no vigilo (a propósito)
No vigilo métricas de negocio. Que las visitas bajen un quince por ciento no es una emergencia, es una conversación conmigo mismo el lunes. Meter eso aquí solo genera ansiedad.
No vigilo cosas que no puedo arreglar. Si un servicio externo se cae, enterarme antes no cambia nada, porque no está en mi mano. Lo único que consigo es preocuparme más rato.
Y no vigilo nada que dependa de que yo interprete el resultado. Si el aviso requiere que yo analice si esto es normal o no, entonces no es un aviso, es una tarea. Y las tareas no van al móvil a las once de la noche.
Lo que me ha ahorrado
Desde que está montado, cuatro cosas se han roto y las cuatro las he arreglado antes de que nadie se quejara. Dos caídas de servidor cortas, un correo automático que dejó de salir y una integración que cambió sin avisar.
Ninguna de las cuatro habría tardado menos de dos días en detectarse antes.
Y hay un beneficio secundario que no esperaba: dejé de comprobar cosas por costumbre. Antes abría la web varias veces al día "por si acaso". Ahora no la abro nunca, porque si estuviera rota me habría enterado.
Confiar en un sistema es lo que hace que puedas dejar de pensar en él. Y eso vale más que el tiempo que ahorras.
Si te interesa esta línea, el hermano mayor de este sistema es el agente que lee tu correo, que hace algo parecido pero con la bandeja de entrada en vez de con la infraestructura. Si quieres montar tu propio sistema de automatizaciones y agentes, con los flujos y las reglas que uso yo a diario, lo enseño entero aquí.
Sigue leyendo
Make vs Zapier: precio, límites y cuál aguanta más
Monté la misma automatización en Make y en Zapier con la factura al lado. Modelos de precio, límites reales y cuál compensa en cada caso.
Precios de Make en 2026: qué compras al subir de plan
El precio de Make en 2026: Core 9 $, Pro 16 $ y Teams 29 $. Los tres traen los mismos créditos, así que lo que compras al subir son funciones.
Manychat vs Chatfuel: montar flujos o un vendedor con IA
Manychat vs Chatfuel: precios, canales, IA y plan gratis comparados. Cuál elegir según si quieres montar el flujo tú o que hable la IA.
Make para una tienda online: seis automatizaciones que sí valen
Automatizar tienda online con Make: seis automatizaciones con sus módulos, los créditos que gasta cada una al mes y qué plan hace falta.