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)
Pestaña Settings del nodo: Retry On Fail y On Error
La pestaña Settings del nodo: aquí están Execute Once, Retry On Fail y On Error

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ónComportamiento
Stop WorkflowValor predeterminado. Se detiene todo el flujo de trabajo y se marca como fallido
ContinueIgnora 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

  1. Añade un flujo de trabajo y ponle el nombre «Notificación de errores».
  2. Selecciona Error Trigger como primer nodo.
  3. 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 }}
  1. Guarda. Los flujos de trabajo que empiezan con Error Trigger funcionan sin necesidad de publicarlos.
Flujo de notificación de errores con Error Trigger conectado a Telegram
Flujo de notificación de errores: Error Trigger recibe la información del fallo y envía un mensaje por Telegram

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

Registro de una ejecución fallida y botón Debug in editor
Las ejecuciones fallidas aparecen en rojo. Ábrela para ver qué nodo produjo el error. Con Debug in editor, en la esquina superior derecha, puedes cargar los datos de ese momento y volver a probar
  • 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ónRecomendación
Llamadas a API externasActiva Retry On Fail
Procesamiento por lotes de varios elementosUsa Continue (using error output) y registra los datos fallidos
No se debe continuar si hay datos incorrectosStop and Error
Todos los flujos en producciónConfigura 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