n8n Error Handling: Cómo Gestionar Errores en tus Workflows

Por / / Blog / 5 minutos de lectura

N8n error handling cómo gestionar es uno de los usos más prácticos de n8n. El error handling en n8n es lo que diferencia un workflow de producción robusto de uno que falla silenciosamente y nadie se entera. En esta guía aprenderás todas las herramientas de n8n para detectar, gestionar y recuperarse de errores en tus automatizaciones.

Por qué los workflows fallan

Los workflows de n8n pueden fallar por múltiples razones:

  • API externa no disponible: el servicio tiene downtime o rate limiting
  • Datos inesperados: el JSON de entrada no tiene el campo que esperabas
  • Credenciales expiradas: el token OAuth dejó de ser válido
  • Timeout: la petición tardó demasiado
  • Errores de lógica: división entre cero, campo null, etc.

Sin error handling, estos fallos pasan desapercibidos hasta que alguien se queja de que algo no funcionó.

Herramienta 1: Error Trigger

El Error Trigger es un nodo especial que se activa cuando cualquier ejecución de un workflow falla. Crea un workflow dedicado a gestionar errores:

  1. Crea un nuevo workflow llamado "Gestor de Errores"
  2. Añade el nodo Error Trigger
  3. Conecta acciones de notificación
Error Trigger
  → Slack — Notificar al equipo técnico
  → Gmail — Email de alerta
  → Airtable — Registrar el error

Datos disponibles en el Error Trigger

El Error Trigger recibe información sobre el error:

  • $json.workflow.name: nombre del workflow que falló
  • $json.execution.id: ID de la ejecución fallida
  • $json.execution.error.message: mensaje de error
  • $json.execution.lastNodeExecuted: el nodo donde se produjo el error
  • $json.execution.url: URL directa a la ejecución en n8n

Mensaje de alerta útil:

🔴 *Error en n8n*

Workflow: {{ $json.workflow.name }}
Nodo: {{ $json.execution.lastNodeExecuted }}
Error: {{ $json.execution.error.message }}
Hora: {{ $now.toLocaleString('es-ES') }}

🔗 Ver ejecución: {{ $json.execution.url }}

Conectar un workflow al Error Trigger

Para que el Error Trigger funcione con un workflow específico, debes vincularlo:

  1. Abre el workflow que quieres monitorizar
  2. Ve a Settings (icono de engranaje)
  3. En Error Workflow, selecciona tu "Gestor de Errores"

Herramienta 2: Continue on Fail

Por defecto, cuando un nodo falla, el workflow se detiene. Con Continue on Fail, puedes hacer que el workflow continúe aunque un nodo falle.

Para activarlo:

  1. Haz clic en los tres puntos (…) del nodo
  2. Ve a Settings
  3. Activa Continue on Fail
  4. Output: elige si quieres que el output sea el error o el output vacío

Útil cuando:

  • Tienes un nodo que puede fallar en algunos items pero no en otros (ej: buscar un registro que puede no existir)
  • Quieres procesar el error de otra forma en lugar de detener todo

Detectar el error después de Continue on Fail

Cuando un nodo falla con Continue on Fail activo, el item lleva información del error:

// En el nodo siguiente, comprueba si hubo error:
$json.error !== undefined

// O en un nodo IF:
// Condition: {{ $json.error }} is not empty

Herramienta 3: Try/Catch con Merge

Para patrones de try/catch más complejos:

Nodo con riesgo de error (Continue on Fail activado)
  → IF — ¿hay error? ($json.error !== undefined)
    → [Rama TRUE] Gestionar el error:
        - Log del error
        - Notificación
        - Valor alternativo
    → [Rama FALSE] Continuar con el flujo normal
  → Merge — combinar ambas ramas
  → Continuar el workflow

Herramienta 4: Reintentos automáticos

Para errores transitorios (API temporalmente caída, rate limiting), configura reintentos:

  1. En el nodo HTTP Request (u otros con llamadas externas)
  2. Despliega Settings
  3. Activa On Error: Retry on Fail
  4. Retry Times: 3 (número de reintentos)
  5. Wait Between Tries: 1000ms (espera entre intentos)

Para errores de rate limiting, aumenta la espera: 5000ms o más.

Herramienta 5: Validar datos antes de procesar

Muchos errores se pueden prevenir validando los datos en el momento de recibirlos:

// Nodo Code: validar datos de entrada
const item = $input.first().json;

const required = ['email', 'nombre', 'empresa'];
const missing = required.filter(field => !item[field]);

if (missing.length > 0) {
  throw new Error(`Campos obligatorios faltantes: ${missing.join(', ')}`);
}

// Si llegamos aquí, los datos son válidos
return [$input.first()];

Al lanzar un error con throw, el workflow falla de forma controlada y el Error Trigger lo captura con el mensaje descriptivo.

Patrón: Reintentar con backoff exponencial

Para APIs con rate limiting estricto, implementa backoff exponencial:

HTTP Request (intento 1) — Continue on Fail
  → IF (error de rate limit — status 429)
    → Wait (1 segundo)
    → HTTP Request (intento 2) — Continue on Fail
    → IF (error de rate limit)
      → Wait (2 segundos)
      → HTTP Request (intento 3)
      → IF (aún error)
        → Error Trigger manual → notificación

Patrón: Dead Letter Queue

Para workflows que procesan muchos items, algunos pueden fallar sin que los demás se vean afectados:

Loop sobre items
  → IF (error al procesar el item)
    → Google Sheets — Añadir a "cola de errores"
    → Slack — Notificación (solo si > 5 errores en el último lote)
  → Continuar con el siguiente item

Los items con error quedan en la "cola de errores" en Sheets para procesarlos manualmente o reintentarlos.

Monitorización de workflows en producción

Para detectar problemas antes de que impacten al negocio:

  1. Activa el Error Workflow en todos los workflows críticos
  2. Revisa las ejecuciones fallidas: en n8n, ve a Executions y filtra por "Error"
  3. Crea un workflow de health check: ejecuta cada hora una petición de prueba a tus workflows críticos
  4. Alertas de tiempo excesivo: si un workflow tarda mucho, puede indicar un problema

Conclusión

El error handling en n8n no es opcional para workflows en producción. Con el Error Trigger para capturar fallos, Continue on Fail para resiliencia y reintentos para errores transitorios, tus workflows son robustos y detectan cualquier problema antes de que cause impacto. Dedica tiempo a configurar el error handling desde el principio: es mucho más fácil que investigar qué falló silenciosamente hace días.

Entradas relacionadas