Qué hacer cuando un workflow de n8n falla de madrugada

Un workflow que sincroniza pedidos con tu ERP se cae a las tres de la mañana. Nadie lo ve. A las nueve, cuando abres la tienda, hay quince pedidos sin facturar y un cliente preguntando dónde está su envío. Eso es peor que no tener automatización: al menos sin ella sabías que tenías que revisarlo a mano.

n8n es la herramienta de automatización que conecta tus aplicaciones (tienda online, CRM, correo, hojas de cálculo) mediante flujos llamados workflows. Cada workflow es una secuencia de pasos, o nodos, que se ejecutan uno tras otro. Si un nodo falla, el workflow entero se detiene ahí.

El problema no es que falle. Los fallos pasan: una API externa que no responde, un token caducado, un archivo con un formato raro. El problema es no enterarte.

El Error Workflow: tu red de seguridad

n8n tiene una función pensada exactamente para esto: el Error Workflow. Es un workflow separado que se dispara automáticamente cuando otro workflow falla. No hace falta que lo llames tú ni que compruebes nada a mano.

Así se configura:

1. Creas un workflow nuevo cuyo único trabajo es reaccionar a errores. Empieza con un nodo Error Trigger.
2. En el workflow que quieres proteger (el que sincroniza pedidos, por ejemplo), vas a Settings y en el campo Error Workflow seleccionas el que acabas de crear.
3. Cuando el workflow original falla, n8n manda automáticamente al Error Workflow los datos del fallo: qué workflow era, en qué nodo se rompió y qué mensaje de error dio.

Ese dato es oro. No es “algo falló”, es “el nodo HTTP Request que llama a la API de tu ERP devolvió un error 500 a las 03:14”.

Un error frecuente de gente que empieza: piensan que cada workflow necesita su propio Error Workflow distinto. No es así. Puedes usar el mismo Error Workflow para todos tus flujos y que él decida, según qué workflow ha fallado, a quién avisar y cómo.

Reintentos: cuándo tienen sentido y cuándo no

Antes de pensar en avisar de un error, pregúntate si el error se podía haber evitado solo con reintentarlo. Muchos fallos de madrugada no son fallos reales: son una API que tarda un segundo más de la cuenta o un servidor que está reiniciándose.

n8n permite configurar reintentos en cada nodo individual, en la pestaña Settings del nodo:

• Retry On Fail: activa que el nodo lo intente de nuevo si falla. Viene desactivado.
• Max Tries: cuántas veces lo intenta antes de rendirse. Por defecto 3, y solo admite entre 2 y 5.
• Wait Between Tries: cuánto espera entre intento e intento. Por defecto 1.000 milisegundos, con un máximo de 5.000.

Ese segundo de espera por defecto se queda corto para lo que suele fallar de madrugada. Si la API del otro lado está reiniciándose, un segundo no le da tiempo a levantarse y los tres intentos se consumen en tres segundos, todos contra un servicio que aún no responde. Subirlo a 5.000 ms convierte tres intentos en quince segundos de margen, que es donde se recuperan de verdad las caídas cortas.

Esto tiene sentido en nodos que llaman a servicios externos inestables: APIs de terceros, webhooks de proveedores, integraciones con bancos. No tiene mucho sentido en nodos que procesan datos internamente (un Set, un IF): si esos fallan, reintentarlos no va a cambiar nada, porque el problema está en la lógica, no en la conexión.

El reintento reduce el ruido. Si tu workflow reintenta y a la tercera lo consigue, no necesitas que nadie te despierte por eso. El aviso solo debe llegar cuando el reintento también ha fallado.

Por qué Telegram y no un correo

Puedes hacer que el Error Workflow te manda un correo. Funciona, pero tiene un defecto real: por la noche no miras el correo, y durante el día se pierde entre facturas y newsletters.

Telegram, la aplicación de mensajería, tiene una ventaja concreta para esto: la notificación llega al móvil como un mensaje normal, con sonido, igual que si te escribiera un compañero. No compite con el filtro de spam ni se queda enterrado en una bandeja de entrada.

Montarlo es sencillo:

1. Creas un bot de Telegram hablando con @BotFather dentro de la propia app. Te da un token.
2. En n8n, añades un nodo Telegram al final de tu Error Workflow.
3. Configuras el token del bot y el Chat ID de la persona o grupo que debe recibir el aviso.
4. En el mensaje, usas los datos que trae el Error Trigger: nombre del workflow, nombre del nodo que falló, y el mensaje de error.

Un mensaje útil no dice “ha habido un error”. Dice: “Workflow Sincronización Pedidos falló en el nodo Actualizar Stock. Error: tiempo de espera agotado.” Con eso ya sabes por dónde empezar a mirar sin abrir n8n primero.

Si tienes más de una persona que debe recibir avisos, mejor un grupo de Telegram que un chat individual: así no depende de que una sola persona esté disponible.

Qué falla en la práctica

Algunas cosas que se suelen pasar por alto al montar esto:

• El propio Error Workflow puede fallar. Si el nodo Telegram no tiene el token bien puesto, el aviso nunca llega y tú sigues sin saberlo. Pruébalo de verdad: fuerza un error en un workflow de prueba y comprueba que el mensaje te llega al móvil.
• Demasiados avisos apagan la señal. Si un workflow falla cada cinco minutos por un problema real y sin resolver, vas a recibir treinta mensajes en una hora y acabarás silenciando el chat. Eso anula toda la protección. Si algo falla de forma repetida, hay que arreglarlo, no solo notificarlo.
• No todos los errores merecen despertarte a las tres de la mañana. Puedes distinguir gravedad según el workflow: si es la sincronización de pedidos, aviso inmediato; si es un informe semanal que puedes revisar al día siguiente, puede esperar. Esto se resuelve con un IF dentro del Error Workflow que decida el canal según qué flujo ha fallado.

Cuándo no merece la pena montar todo esto

Si tienes uno o dos workflows sencillos que revisas cada mañana de todas formas, un Error Workflow con Telegram es más aparato del que necesitas. La complejidad de mantenerlo puede superar el beneficio.

Donde sí compensa claramente es en workflows que tocan dinero, stock o comunicación con clientes por WhatsApp, y que corren sin que nadie los mire: ahí un fallo silencioso de ocho horas cuesta más que el rato que se tarda en configurar el aviso. Un webhook de WhatsApp caído son mensajes de clientes que no llegan a ninguna parte y de los que nadie se entera hasta que uno se queja.

En resumen

Un Error Workflow con Telegram no evita que las cosas fallen. Evita que te enteres tarde. Configura primero los reintentos para filtrar el ruido de errores temporales, y deja el aviso solo para lo que de verdad necesita que alguien mire ahora mismo, no mañana.

Esta vigilancia es parte de lo que entregamos con cada proyecto de automatización de procesos con n8n: un flujo sin avisos configurados está a medio montar.