Crea un workflow de errores en n8n y vincúlalo a un workflow en producción
Tutorial paso a paso para crear un workflow de errores en n8n con Error Trigger, vincularlo en los ajustes, probarlo y resolver campos ausentes.
Comprobado con las fuentes citadas el .
El objetivo y lo que necesitas antes de empezar
El objetivo de este tutorial es un único workflow de alertas compartido: cuando una automatización en producción falla, un workflow de errores de n8n se ejecuta automáticamente y avisa a tu equipo de qué se ha roto. Lo construyes una vez y lo vinculas a todos los workflows que te importan.
El nodo Error Trigger es el punto de entrada para esto. Cuando otro workflow vinculado falla, el Error Trigger recibe los detalles del fallo y ejecuta tu workflow de errores. La documentación de n8n es explícita: un workflow de errores debe empezar con ese nodo, y el mismo workflow de errores se puede reutilizar en muchos workflows.
Antes de empezar, ten tres cosas listas: una instancia de n8n que puedas editar, un workflow guardado que se ejecute automáticamente y que quieras proteger, y un canal de notificación con credenciales que funcionen, como un nodo de chat o de correo.
Sources: Error Trigger | Nodes | n8n Docs, Handle errors gracefully | Build | n8n Docs
Crea y vincula el workflow de errores, paso a paso
Cuatro pasos te llevan de un lienzo vacío a un sistema de alertas verificado. La lista ordenada de abajo es el núcleo de este tutorial; los párrafos posteriores explican los detalles que suelen hacer tropezar.
- Crea un workflow nuevo, añade el Error Trigger como su primer nodo y guárdalo con un nombre claro como Error Handler.
- Añade tu nodo de notificación después del trigger y mapea los campos del error en el mensaje.
- Abre el workflow de producción, ve a Options y luego a Settings, selecciona tu Error Handler en Error workflow y guarda.
- Añade un nodo Stop And Error a una rama del workflow de producción, deja que se ejecute automáticamente y confirma que llega la alerta.
En el segundo paso, mapea los datos que te da el Error Trigger. El payload de ejemplo documentado incluye el id y la url de la ejecución, el mensaje y el stack del error, lastNodeExecuted, el modo de ejecución, y el id y el nombre del workflow. Como sugerencia editorial, pon el nombre del workflow, su id y lastNodeExecuted en la primera línea de tu alerta, para que quien esté de guardia pueda triar antes de abrir n8n.
El tercer paso es la vinculación en sí. En el workflow que quieres proteger, elige Options, luego Settings, después selecciona tu workflow de errores en el ajuste Error workflow y guarda. Ese ajuste se describe en la documentación de ajustes de workflow como la elección de un workflow que se dispara si el workflow actual falla. La documentación de n8n no indica números de versión para estas páginas, así que el texto de los menús puede variar según tu edición.
El cuarto paso es la verificación. El nodo Stop And Error fuerza que las ejecuciones fallen en las circunstancias que tú elijas y dispara el workflow de errores, lo que lo convierte en una forma limpia de probar el montaje sin esperar a una caída real.
Sources: Error Trigger | Nodes | n8n Docs, Handle errors gracefully | Build | n8n Docs, Configure workflow settings | Build | n8n Docs
Resultados esperados y cómo leerlos
Tras una ejecución automática fallida, tu workflow de errores de n8n se ejecuta solo y llega tu notificación. Abre Executions para confirmarlo: puedes revisar las ejecuciones de un único workflow o de todos los workflows a los que tienes acceso, y también puedes activar el log streaming.
No todos los campos están siempre presentes, y eso es un comportamiento documentado, no un fallo. El id y la url de la ejecución requieren que la ejecución se haya guardado en la base de datos, y no aparecen cuando el propio nodo trigger del workflow principal da error. El campo retryOf solo aparece en ejecuciones reintentadas.
La tabla de abajo resume qué esperar de cada parte del payload cuando diseñes tu mensaje de alerta.
| Campo | Qué te indica | Cuándo puede faltar |
|---|---|---|
| execution.id | Qué ejecución ha fallado | La ejecución no se guardó en la base de datos |
| execution.url | Enlace directo a la ejecución | El nodo trigger del workflow principal dio error |
| execution.error | Mensaje y stack | Desconocido |
| execution.lastNodeExecuted | Dónde se detuvo | Desconocido |
| execution.retryOf | La ejecución original reintentada | Solo presente en reintentos |
| workflow.id y name | Qué automatización se ha roto | Desconocido |
Sources: Error Trigger | Nodes | n8n Docs, Handle errors gracefully | Build | n8n Docs
Solucionar un workflow de errores de n8n que no dice nada
La sorpresa más habitual es el silencio durante las pruebas. La documentación indica que no puedes probar los workflows de errores ejecutando un workflow manualmente: el Error Trigger se dispara cuando falla una ejecución automática. Deja que el schedule, el webhook u otro trigger hagan el trabajo en lugar de pulsar Execute.
Si llegan las alertas pero el enlace a la ejecución no funciona, revisa los ajustes de retención en el mismo modal de ajustes, que controlan si se guardan las ejecuciones fallidas de workflows publicados. En n8n autoalojado, el pruning a nivel de instancia también elimina los datos de ejecución tras una antigüedad configurable, con un valor por defecto documentado de 336 horas.
Del fallo a una alerta triada
- Falla una ejecución automática: Una ejecución programada o lanzada por webhook da error en un nodo.
- Se dispara el Error Trigger: El workflow de errores vinculado arranca y recibe los detalles del fallo.
- Se compone el mensaje: El nombre del workflow, su id y el último nodo ejecutado entran en el texto de la alerta.
- Se avisa al equipo: El nodo de notificación entrega la alerta al canal que hayas elegido.
- Se revisa la ejecución: Alguien abre Executions para inspeccionar la ejecución fallida.
Decide también qué fallos merecen la atención de una persona. La documentación del nodo HTTP Request describe cómo activar Retry on Fail con Max Tries y Wait Between Tries en milisegundos, algo útil frente a respuestas de límite de tasa; así los fallos pasajeros se recuperan sin avisar a nadie.
Un tutorial antiguo del blog de n8n escrito por Tanay Pant, publicado en 2020 y construido con n8n 0.111.0, combina un Error Trigger con nodos de notificación y un segundo workflow roto a propósito. Los nombres de nodos y la interfaz han cambiado desde entonces, así que trata ese artículo como un patrón ilustrativo y no como pasos actuales.
Sources: Error Trigger | Nodes | n8n Docs, Configure workflow settings | Build | n8n Docs, Executions | Deploy | n8n Docs, Common Issues | Nodes | n8n Docs, Creating error workflows in n8n – n8n Blog
Prácticas de equipo y buenas prácticas de n8n en la gestión de errores
Cuando el patrón funcione, conviértelo en una convención y no en una costumbre personal. Como un mismo workflow de errores de n8n puede servir a muchos workflows, acordad en equipo que toda automatización que pase a producción lleve el Error Handler compartido vinculado antes de activarse, y añadid esa línea a vuestra checklist de revisión.
Esa única convención es el núcleo de las buenas prácticas de n8n en la gestión de fallos: un handler con dueño, vinculado de forma deliberada y probado antes del lanzamiento. La documentación de n8n no mide cuánto más rápido resuelven los incidentes los equipos después, así que trata el beneficio como claridad operativa y no como una métrica probada.
Sources: Handle errors gracefully | Build | n8n Docs
