Monitorizar los workflows de n8n: por qué un estado «éxito» no demuestra nada

Una automatización que falla con estruendo no es el problema. El problema es la que se para sin decir nada: las solicitudes de sus clientes dejan de llegar al CRM, los planning dejan de salir, y usted se entera tres semanas después, por un cliente. Así monitorizamos nuestros propios workflows de n8n, y esto es lo que aprendimos a base de golpes.

Las averías que no hacen ruido

• Un workflow desactivado. Alguien lo apaga para una prueba, o una actualización lo desactiva. Ya no se ejecuta, así que ya no falla, así que nadie se entera.
• Una credencial caducada. Una aplicación de Google en modo de prueba pierde su autorización a los siete días. El workflow se ejecuta, la llamada falla.
• Un error tragado. Un paso configurado para continuar en caso de error deja pasar una respuesta vacía. La ejecución termina en verde. El resultado no existe.
• Una API que cambia. Un proveedor renombra un campo. El workflow lee un valor vacío y escribe una ficha incompleta, cada día, sin rechistar.
• Un disparador que ya no dispara. El formulario de su web está roto: el webhook nunca se llama. n8n no tiene nada que reprochar, no ha recibido nada.

Por qué el workflow de error de n8n no basta

n8n ofrece un mecanismo nativo: un workflow de error que se dispara cuando una ejecución falla. Es útil y lo usamos. Pero solo cubre una de las averías anteriores. No ve un workflow desactivado, ni un error tragado, ni un disparador mudo. Y no ve nada si el propio servidor de n8n está caído.

Nivel 1: el estado

¿Lo que debe ejecutarse se está ejecutando? Cada cinco minutos, un workflow de monitorización consulta la API de n8n. Lista los workflows marcados como «deben seguir activos» (para nosotros, con una etiqueta) y comprueba que lo están. Lista las ejecuciones fallidas desde la última pasada. Llama a las direcciones públicas que importan, web y formularios, y comprueba que responden.

Nivel 2: el resultado

¿Existe lo que el workflow debía producir? Un estado «éxito» dice que los pasos se han encadenado, no que la ficha se haya creado ni que el mensaje haya llegado. Nuestra regla: cada cadena termina con un paso que relee el resultado real. Si la relectura falla, la ejecución falla, y el nivel 1 la ve.

Nivel 3: la ausencia

¿Ha ocurrido lo que tenía que ocurrir? Un formulario que no recibe nada en cinco días cuando suele recibir tres solicitudes al día no es casualidad. De ahí un principio: un mensaje esperado siempre sale, aunque no haya nada que decir. Así el silencio conserva su sentido: significa avería.

Una alerta que se lee

1. Una alerta y un recordatorio espaciado. Una alerta al detectar, un recordatorio cada hora mientras dure el problema.
2. Un mensaje de vuelta a la normalidad. Sin él, nadie sabe si alguien se ha ocupado.
3. El canal adecuado. Una mensajería que se mira de verdad, para nosotros Telegram, con el nombre del workflow y la causa en claro.

¿Y quién vigila al vigilante?

Si el servidor de n8n cae, el workflow de monitorización cae con él. Hace falta una mirada exterior, aunque sea mínima: un servicio externo que llame a su n8n y avise si deja de responder.

La copia de seguridad forma parte de la monitorización

Cada noche, nuestra monitorización exporta todos los workflows por la API y los envía a un lugar separado del servidor. La base de datos completa se respalda además a nivel de servidor. Restaurar un workflow lleva entonces cinco minutos en lugar de un día de reconstrucción de memoria.

Preguntas frecuentes

¿Cómo recibir una alerta cuando un workflow de n8n se para?

Con un workflow de monitorización que consulta la API de n8n cada cinco minutos: comprueba que los workflows marcados como activos lo están, lista las ejecuciones fallidas y avisa por una mensajería que se lee, como Telegram. El workflow de error nativo no basta porque no detecta un workflow desactivado.

¿Basta el workflow de error de n8n para monitorizar?

No. Solo se dispara cuando una ejecución falla. No detecta un workflow desactivado, un error ignorado por un paso configurado para continuar, un disparador que ya no recibe nada ni un servidor parado.

¿Por qué una ejecución de n8n puede tener éxito sin producir nada?

Porque «éxito» solo indica que los pasos se han encadenado. Un paso que continúa en caso de error o una API que devuelve una respuesta vacía dejan la ejecución en verde. Cada cadena debe terminar releyendo el resultado real.

¿Cómo hacer copia de seguridad de los workflows de n8n?

Exportando cada noche todos los workflows por la API de n8n a un almacenamiento separado del servidor, y respaldando además la base de datos completa a nivel de servidor.