Contenido
Tutorial de gestión de errores en n8n: reintentos, continuar tras un fallo y notificaciones
Lo peor que puede pasarle a un flujo de automatización es que falle en silencio: una API no está disponible temporalmente, el formato de los datos no es correcto, las credenciales han caducado… Si nadie se da cuenta, puede que no se envíen notificaciones durante varios días. En esta sección conocerás los mecanismos de gestión de errores de n8n.
1. Reintentos automáticos (Retry On Fail)
Muchos errores son temporales (una conexión de red inestable o una API que agota el tiempo de espera de vez en cuando). En la pestaña Settings del nodo:
- Retry On Fail: actívalo
- Max Tries: número máximo de intentos, por ejemplo, 3
- Wait Between Tries (ms): intervalo entre intentos, por ejemplo, 5000 (5 segundos)

Es adecuado para nodos que llaman a API externas (HTTP Request y nodos de distintos servicios).
2. Qué hacer si se produce un fallo (On Error)
También en la pestaña Settings del nodo, On Error ofrece tres opciones:
| Opción | Comportamiento |
|---|---|
| Stop Workflow | Valor predeterminado. Se detiene todo el flujo de trabajo y se marca como fallido |
| Continue | Ignora el error, incluye el mensaje de error en la salida y continúa con los nodos siguientes |
| Continue (using error output) | Añade una salida error al nodo y envía los datos fallidos por otra ruta |
Usar una rama de salida de error
Al procesar varios elementos, el fallo de uno no debería detener los demás:
┌─ success ─▶ [Marcar como procesado]
[Llamar a la API por elemento] ─┤
└─ error ───▶ [Registrar en la hoja de cálculo «Lista de fallos»]
El elemento de datos que ha fallado incluye un mensaje de error que puedes leer con {{ $json.error.message }}.
3. Detención explícita: Stop and Error
Si los datos no cumplen lo esperado, es mejor detener el flujo explícitamente que dejar que los nodos siguientes generen resultados incorrectos:
[Obtener pedido] ─▶ [If ¿el importe está vacío?] ─true─▶ [Stop and Error: «Al pedido {{ $json.id }} le falta el importe»]
└false─▶ [Continuar el procesamiento]
El nodo Stop and Error hace que la ejecución falle y activa el flujo de gestión de errores que se describe a continuación.
4. Notificaciones globales de errores: Error Trigger
Este es el paso más importante: crea un flujo de trabajo dedicado a gestionar errores que te envíe una notificación automáticamente cuando falle cualquier flujo.
Crear un flujo de trabajo para errores
- Añade un flujo de trabajo y ponle el nombre «Notificación de errores».
- Selecciona Error Trigger como primer nodo.
- Conecta un nodo de notificación (Telegram, Email, Slack, etc.) con este contenido:
⚠️ Falló la ejecución del flujo de trabajo de n8n
Flujo: {{ $json.workflow.name }}
Nodo: {{ $json.execution.lastNodeExecuted }}
Error: {{ $json.execution.error.message }}
Hora: {{ $now.toFormat('yyyy-MM-dd HH:mm') }}
Ver: {{ $json.execution.url }}
- Guarda. Los flujos de trabajo que empiezan con Error Trigger funcionan sin necesidad de publicarlos.

Asignarlo a otros flujos de trabajo
En cada flujo que quieras supervisar, ve a Menú → Settings → Error workflow y selecciona «Notificación de errores».
A partir de entonces, se enviará una notificación automáticamente cuando ese flujo termine con el estado «fallido».
El flujo de errores solo se activa cuando falla una ejecución automática (programación, Webhook, etc.); no se activa si falla una prueba manual.
5. Consultar y volver a ejecutar

- En Executions, filtra por el estado Error para ver todas las ejecuciones fallidas.
- Abre una ejecución fallida y pulsa Debug in editor para volver a probarla con los datos de ese momento.
- Después de corregir el problema, puedes volver a ejecutar esa ejecución fallida.
6. Mantener la trazabilidad de los datos
- En Settings, configura la política de conservación del historial de ejecuciones: puedes guardar solo las ejecuciones fallidas para ahorrar espacio en la base de datos.
- En los flujos importantes, puedes guardar un registro al final en una hoja de cálculo o una base de datos para consultar más adelante «qué dato se procesó y cuándo».
Prácticas recomendadas
| Situación | Recomendación |
|---|---|
| Llamadas a API externas | Activa Retry On Fail |
| Procesamiento por lotes de varios elementos | Usa Continue (using error output) y registra los datos fallidos |
| No se debe continuar si hay datos incorrectos | Stop and Error |
| Todos los flujos en producción | Configura Error workflow |
Adquiere el hábito de configurar las notificaciones de errores al crear cada flujo de trabajo que vaya a funcionar a largo plazo.
Actualizado 12 de octubre de 2026