Un workflow que trabaja solo tiene un problema: cuando falla, también falla solo. El error se queda en la pestaña Executions, donde nadie mira, y puedes pasar tres días sin enterarte de que tu workflow de cada mañana no está haciendo nada. La solución es un workflow de errores que te avise por Telegram en cuanto algo se rompe.

Este es el capítulo 10 de n8n desde cero, nuestra serie gratuita en YouTube. Aquí tienes el vídeo y, debajo, el paso a paso para montarlo aunque no le des al play, con los dos workflows terminados para descargar.

Cómo funciona un workflow de errores en n8n

La idea es sencilla. Montas un segundo workflow que empieza con el nodo Error Trigger y, en los ajustes del primero, le dices: si fallas, avisa a este. Cuando el primero falla, n8n arranca el de errores y le pasa todo lo que ha ocurrido.

Un mismo workflow de errores te vale para todos los demás: en cada workflow que quieras vigilar eliges el mismo en Settings. Como el aviso lleva el nombre del que ha fallado, siempre sabrás cuál ha sido.

Qué necesitas antes de empezar

• El bot de Telegram del capítulo 3 y tu chat id.
• Un workflow que quieras vigilar. En el vídeo usamos «Previsión de cada mañana»: un Schedule Trigger a las siete, un HTTP Request que pide la previsión del tiempo a Open-Meteo (como en el capítulo 7) y un nodo de Telegram que se la manda a la panadería. Viene en la descarga.

El paso a paso

1. El Error Trigger

Crea un workflow nuevo y ponle nombre; el nuestro se llama Avisos de error. Pulsa el más, busca error y elige Error Trigger. No tiene nada que configurar.

2. Qué datos trae: Fetch Test Event

Pulsa Fetch Test Event. Como todavía no ha fallado nada, te enseña un error de ejemplo con los datos que vas a usar:

3. El aviso por Telegram

Detrás del Error Trigger añade Telegram, Send a text message, con el bot del capítulo 3 y tu chat id, y llámalo Avisar del error. Cada dato va como expresión, entre dobles llaves. El texto del workflow descargable es este:

Ha fallado el workflow {{ $json.workflow.name }}
Nodo: {{ $json.execution.lastNodeExecuted }}
Error: {{ $json.execution.error.message }}
Ver la ejecución: {{ $json.execution.url }}

4. Publica el workflow de errores

Guarda y pulsa Publish. En n8n 2.43 es obligatorio: si el workflow de errores no está publicado, no te deja elegirlo en los ajustes de los demás, aunque la documentación todavía diga que no hace falta. Publicarlo no hace que se ejecute solo, porque únicamente arranca cuando falla otro.

5. Elígelo en Settings del workflow vigilado

Vuelve al workflow que quieres vigilar. Arriba, junto al nombre, pulsa los tres puntos y Settings. En Error Workflow (to notify when this one errors) elige Avisos de error y pulsa Save.

Lo rompemos a propósito

Para simular que la API se cae, cambiamos la URL del HTTP Request por una dirección de pruebas que siempre contesta que el servicio no está disponible:

https://httpbin.org/status/503

Pulsamos Execute y el HTTP Request se pone en rojo, pero el aviso no llega, y no está roto: el Error Trigger solo salta con ejecuciones automáticas, como las del Schedule Trigger cuando el workflow está publicado, y las ejecuciones que lanzas a mano desde el editor no cuentan.

El truco: reintentar desde Executions

Para probarlo sin publicar el vigilado ni esperar a las siete de la mañana, abre la pestaña Executions. Las ejecuciones manuales llevan el icono del matraz. Abre la que ha fallado, pulsa el botón de reintentar y elige Retry with currently saved workflow. Ese reintento ya no cuenta como manual: vuelve a fallar y, ahora sí, salta el workflow de errores.

El aviso llega al móvil con el nombre del workflow, el nodo Previsión del tiempo, el error de servicio no disponible y el enlace directo a la ejecución. En el mensaje de error, n8n sugiere además activar los reintentos del nodo.

Retry On Fail y On Error

Los reintentos ya salieron en el capítulo 7. En el HTTP Request, pestaña Settings, activa Retry On Fail: Max. Tries son los intentos y Wait Between Tries, la espera entre uno y otro. El workflow descargable usa 3 intentos y 2000 ms. Así un corte de unos segundos no te molesta, porque el aviso solo llega si fallan todos los intentos.

Justo debajo está On Error, y aquí hay que tener cuidado:

Si eliges cualquiera de las dos opciones de Continue, ese error lo tienes que tratar tú dentro del workflow. Si lo que quieres es el aviso, déjalo en Stop Workflow.

Stop and Error: cuando los datos llegan mal

A veces la API contesta bien, pero sin lo que esperas, y n8n no lo ve como un error. Para eso está Stop and Error. En el workflow vigilado, detrás del HTTP Request hay un IF llamado ¿Hay previsión? que comprueba si ha llegado daily, el bloque con la previsión.

En la salida false del IF pulsa el más y busca Stop and Error. En Error Type deja Error Message y escribe tu mensaje: «La previsión ha llegado vacía». Es el texto que te llegará en el aviso.

Para probarlo, cambia la URL por esta otra, que contesta bien pero con otros datos:

https://httpbin.org/json

Al pulsar Execute, el IF lo manda por false y Stop and Error para el workflow con tu mensaje. Reinténtalo desde Executions como antes y llegará el aviso, con Stop and Error como nodo y «La previsión ha llegado vacía» como error.

Cuando acabes, vuelve a poner la URL de Open-Meteo y publica el workflow vigilado para que trabaje solo. Nosotros no lo publicamos porque es de prueba.

Punto de control y consejos

Al terminar tienes que tener un workflow de errores publicado, que empieza por Error Trigger y avisa por Telegram, y en cada workflow que vigilas, ese mismo elegido en Settings.

El mensaje de error puede llevar trozos de los datos que se procesaban, así que piensa a quién le llega el aviso. El workflow de errores también puede fallar: que no dependa del mismo servicio que vigila, y pruébalo de vez en cuando con un reintento.

Si te falla

• No llega el aviso: comprueba si lo ejecutaste a mano, si guardaste Settings en el vigilado y si el de errores está publicado y empieza por Error Trigger.
• No aparece en la lista de Error Workflow: publícalo primero.
• El aviso llega sin enlace: el fallo fue en el disparador, y ahí no hay ejecución que enlazar.
• Falla el nodo y no hay aviso: revisa que On Error esté en Stop Workflow.

Los capítulos del vídeo

Preguntas frecuentes

¿Por qué no me llega el aviso del workflow de errores?
Lo más habitual es que hayas ejecutado el workflow a mano: el Error Trigger solo salta con ejecuciones automáticas. Revisa también que guardaste Settings en el vigilado y que el de errores está publicado y empieza por Error Trigger.

¿Hay que publicar el workflow de errores?
En n8n 2.43, sí: si no está publicado, no aparece para elegirlo en Settings > Error Workflow. Publicarlo no hace que se ejecute solo, porque solo arranca cuando falla otro workflow.

¿Cómo pruebo el aviso sin esperar a que algo falle de verdad?
Rompe el workflow con https://httpbin.org/status/503, ejecútalo, ve a Executions, abre la ejecución fallida y reinténtala con Retry with currently saved workflow. Ese reintento cuenta como automático y dispara el aviso.

¿Necesito un workflow de errores para cada workflow?
No. Uno solo te vale para todos: lo eliges en Settings de cada workflow que quieras vigilar, y el aviso lleva el nombre del que ha fallado.

¿Para qué sirve el nodo Stop and Error?
Para fallar a propósito con tu propio mensaje cuando los datos llegan mal aunque la API haya contestado bien. Ese mensaje es el que te llega en el aviso.

Sigue la serie: ← capítulo 9: Gmail clasificado con IA · todos los capítulos de n8n desde cero. La serie continúa con capítulos nuevos, que irán apareciendo en el índice.