Gestión de errores en n8n: error workflows y notificaciones de errores

Un error workflow es en n8n una automatización completamente normal que se configura en los ajustes del workflow bajo "Error workflow" y que se inicia automáticamente en cuanto falla la ejecución de otro workflow. Combinado con el nodo Error Trigger, los ajustes de Retry On Fail de nodos individuales y una notificación por correo electrónico o Microsoft Teams, esto permite garantizar que los errores no pasen desapercibidos, sino que se repitan automáticamente o se notifiquen al equipo responsable. Actualizado: julio de 2026.

¿Qué es un error workflow y cuándo se activa?

Según la documentación de n8n, un error workflow es un workflow separado que se configura "en Workflow Settings" para otra automatización y que se ejecuta en cuanto falla la ejecución de esta. Un caso de uso típico, según la documentación, es enviar "notificaciones por correo electrónico o Slack" en caso de error. Un único error workflow puede reutilizarse para varios workflows productivos, de modo que no es necesario crear una gestión de errores propia para cada automatización. Es importante tener en cuenta que un error workflow no se puede probar ejecutándolo manualmente: según la documentación, el Error Trigger solo reacciona cuando la ejecución automatizada de otro workflow realmente falla. Encontrará más detalles en la documentación de n8n sobre gestión de errores.

¿Cómo se configura un error workflow?

Primero crea un workflow independiente que existe exclusivamente para el caso de error, y después lo vincula con el workflow que desea supervisar.

• Crear el workflow gestor de errores: Cree un nuevo workflow con el Error Trigger como primer nodo, asígnele un nombre como "Error Handler" y guárdelo.
• Abrir el workflow de destino: Abra el workflow cuyos errores desea supervisar y vaya allí a Options y luego a Settings.
• Asignar el error workflow: En el campo "Error workflow" seleccione el workflow gestor de errores creado anteriormente y guarde el ajuste.

Un workflow que solo se inicia a través del Error Trigger no necesita publicarse por separado para funcionar como error workflow.

¿Qué información proporciona el Error Trigger en caso de error?

El Error Trigger transmite datos estructurados sobre la ejecución fallida, a partir de los cuales se puede componer una notificación significativa. Según la documentación del nodo Error Trigger estos datos incluyen, entre otros:

• execution.id y execution.url: identificador y enlace a la ejecución fallida, pero faltan si el error ya se produce en el nodo disparador de la automatización principal.
• execution.error: el mensaje de error propiamente dicho, incluida la traza de la pila (stack trace).
• execution.lastNodeExecuted: el nodo en el que falló la ejecución.
• execution.retryOf: presente solo si la ejecución fallida ya era en sí misma una repetición.
• workflow.id y workflow.name: qué workflow se ve afectado.

Además, con el nodo Stop And Error se puede forzar deliberadamente un error, por ejemplo, para activar intencionadamente el error workflow ante datos inverosímiles, aunque técnicamente no exista ningún error de nodo.

¿Cómo se puede repetir automáticamente una llamada fallida mediante Retry?

Antes de que una ejecución se considere definitivamente fallida y termine en el error workflow, cada nodo individual se puede configurar para que primero repita automáticamente varias veces una llamada fallida. Para ello, abra el nodo correspondiente, vaya a los ajustes y active allí "Retry On Fail". Con "Max Tries" define cuántas veces n8n repite el intento, con "Wait Between Tries (ms)" el tiempo de espera entre los intentos en milisegundos. Ambos valores están limitados según la documentación sobre el manejo de los límites de tasa (rate limits) de la API: Max Tries a un máximo de 5, Wait Between Tries a un máximo de 5000 milisegundos. Especialmente en servicios con límites de tasa, la documentación recomienda fijar el tiempo de espera por encima del intervalo de límite de tasa de la API correspondiente, para que el siguiente intento no sea rechazado de nuevo.

¿Cómo notifica a su equipo por correo electrónico o Microsoft Teams?

Después del Error Trigger, simplemente añada en el error workflow el nodo mediante el cual se enviará la notificación. Para las notificaciones por correo electrónico es adecuado el nodo Send Email, que requiere una conexión con credenciales SMTP y envía los mensajes como texto, HTML o ambos formatos. Para el aviso en un canal de Teams está disponible el nodo Microsoft Teams, que publica mensajes en un canal mediante credenciales de Microsoft almacenadas. En ambos casos, se construye el texto del mensaje a partir de los campos proporcionados por el Error Trigger, como el nombre del workflow, el mensaje de error de execution.error y el enlace a la ejecución mediante execution.url, para que los destinatarios reconozcan de inmediato qué proceso se ve afectado y dónde pueden consultar los detalles. Quien desee asegurar de forma técnicamente fundamentada un entorno n8n existente con error workflows, estrategias de Retry y notificaciones encontrará apoyo en los servicios de n8n de NordFlux.

Preguntas frecuentes sobre la gestión de errores en n8n

¿Necesito un error workflow propio para cada workflow?

No, un único error workflow puede configurarse en los ajustes de varios workflows como error workflow compartido. Así, a menudo basta una automatización de notificación centralizada para muchos workflows productivos. Para procesos especialmente críticos, aun así puede crear un error workflow especializado con su propia lógica de escalado.

¿Puedo probar un error workflow manualmente?

No, según la documentación de n8n, un error workflow no se puede probar ejecutándolo manualmente, ya que el Error Trigger solo reacciona cuando la ejecución automatizada de otro workflow realmente falla. Para comprobar de todos modos este comportamiento, puede usar en un workflow de prueba el nodo Stop And Error para forzar deliberadamente un error y así activar el error workflow vinculado.

¿Cuál es la diferencia entre Retry On Fail y un error workflow?

Retry On Fail repite automáticamente la llamada de un único nodo dentro de la misma ejecución, mientras que el error workflow solo entra en acción cuando toda la ejecución ha fallado definitivamente a pesar de todos los intentos de repetición. Ambos mecanismos se complementan de forma útil: los retries absorben interrupciones a corto plazo, como límites de tasa superados, y el error workflow informa posteriormente a las personas sobre los fallos definitivos.

¿El workflow gestor de errores debe estar activado o publicado?

No, un workflow que se inicia exclusivamente a través del Error Trigger no necesita, según la documentación, publicarse por separado para funcionar. Se llama automáticamente en cuanto otro workflow lo referencia en sus ajustes como error workflow y él mismo falla.