Error handling en n8n: por qué casi nadie lo hace bien y cómo montarlo con error workflows dedicados

Cuando un workflow de n8n falla a las 3 de la madrugada, hay dos tipos de usuarios: los que se enteran a las 9 cuando el cliente les escribe preguntando qué pasó, y los que ya recibieron la alerta a las 3:01 con el nodo exacto que falló y el mensaje de error completo.

La diferencia no es suerte. Es si tienes error handling o no.

El error más común: depender del panel de ejecuciones

La mayoría de la gente que empieza con n8n hace lo mismo. Construye el workflow, lo activa, y asume que si algo va mal lo verá en la pestaña “Executions”. Técnicamente es verdad. Prácticamente, nadie mira esa pestaña cada hora.

El resultado es que los workflows fallan en silencio durante días. Un webhook que dejó de recibir datos porque el proveedor cambió el formato. Un HTTP Request que empezó a devolver 429 porque se superó el rate limit. Un nodo de base de datos que falla porque una columna ya no existe. Todo queda registrado en Executions, pero nadie lo ve.

El panel de ejecuciones es para diagnóstico, no para monitorización. Son cosas distintas.

Por qué la gente no monta error handling

Hay tres razones reales, ninguna es vagancia:

Primera: parece opcional. n8n funciona sin error handling. Los workflows corren, los datos se procesan, todo parece bien. El coste de no tenerlo es diferido — solo se paga cuando algo falla en producción.

Segunda: la documentación oficial lo explica tarde. La mayoría de tutoriales de n8n se centran en construir el flujo feliz. El error handling aparece como apartado avanzado, como si fuera algo para cuando ya dominas la herramienta. No lo es.

Tercera: la opción “Continue on Error” confunde. Cada nodo tiene una opción para continuar aunque falle. Mucha gente la activa para “que no se corte el workflow” sin entender que así están ocultando errores, no manejándolos.

Cómo funciona el error handling en n8n de verdad

n8n tiene un mecanismo específico para esto: los Error Workflows. No es una configuración de nodo ni un truco — es una funcionalidad de primer nivel que muy poca gente usa.

Funciona así: en la configuración de cada workflow (Settings → Error Workflow), puedes designar otro workflow que se ejecutará automáticamente si el primero falla. Ese workflow de error recibe como datos de entrada toda la información del fallo: qué nodo falló, cuál fue el mensaje de error, en qué workflow ocurrió, y el timestamp exacto.

La variable de entrada se llama $json como siempre, y contiene una estructura así:

{
  "workflow": {
    "id": "12",
    "name": "Sync pedidos Shopify"
  },
  "execution": {
    "id": "445",
    "url": "https://tu-instancia.n8n.cloud/workflow/12/execution/445"
  },
  "lastNodeExecuted": "HTTP Request",
  "error": {
    "message": "Request failed with status code 401",
    "timestamp": 1722300000000
  }
}

Con eso puedes construir una alerta útil. No solo “algo falló”, sino exactamente qué, dónde, cuándo, y un enlace directo a la ejecución fallida para ir a verla.

Un error workflow básico que funciona

El error workflow más sencillo que funciona en producción tiene tres nodos:

1. Trigger: Error Trigger — este nodo especial recibe los datos del fallo automáticamente. No necesitas configurarlo, solo añadirlo.

2. Set — para construir el mensaje con los datos que importan. Algo así:

   ⚠️ Fallo en: {{ $json.workflow.name }}
   Nodo: {{ $json.lastNodeExecuted }}
   Error: {{ $json.error.message }}
   Ver ejecución: {{ $json.execution.url }}

3. Telegram / Slack / Email — donde quieras recibir la alerta.

Con eso ya tienes monitorización real. El workflow falla, en menos de un minuto tienes la notificación en el móvil con todo lo necesario para diagnosticar.

El paso que nadie hace: un error workflow centralizado

La trampa con el sistema de Error Workflows de n8n es que hay que configurarlo en cada workflow por separado. Si tienes 20 workflows y cada uno tiene que apuntar a su propio error workflow, son 20 sitios donde mantener la lógica de alertas.

La solución es tener un único error workflow que usen todos los demás. Lo creas una vez, lo refinas cuando quieras, y todos los workflows apuntan al mismo.

Así funciona en la práctica: creas un workflow llamado “Error Handler Central”, lo construyes bien (alerta de Telegram, log en una hoja de cálculo, lo que necesites), y en cada workflow nuevo vas a Settings → Error Workflow → seleccionas “Error Handler Central”. Un minuto por workflow, una vez.

Cuando quieres mejorar la alerta (añadir más contexto, cambiar el canal, guardar un registro), lo cambias en un solo sitio y aplica a todos.

Añadir contexto útil desde el workflow principal

El error workflow recibe los datos estándar del fallo, pero a veces no son suficientes. Por ejemplo, si tienes un workflow que procesa pedidos de Shopify y falla, saber que falló el nodo “HTTP Request” no te dice qué pedido estaba procesando.

Para eso existe una técnica: antes de los nodos que pueden fallar, usa un nodo Set para guardar contexto relevante en las propiedades de la ejecución. n8n permite añadir notas personalizadas a la ejecución que luego aparecen en el panel.

La alternativa más práctica: en el error workflow, no dependas solo de los datos que llegan automáticamente. Configura el workflow principal para que guarde el estado en una variable de entorno o en un campo de la base de datos antes de procesar cada ítem. Si falla, el error workflow puede leer ese estado y saber exactamente en qué punto estaba.

Qué hacer con los errores recuperables

No todos los errores son iguales. Un 429 (rate limit) es recuperable — esperas unos segundos y reintenta. Un 401 (no autorizado) no es recuperable sin intervención humana. Un 500 del servidor externo puede ser transitorio o puede ser que ese servicio se cayó.

El error workflow puede tener lógica para distinguirlos:

• Si $json.error.message contiene “429”, el error workflow puede encolarlo para reintento automático en 60 segundos usando un nodo Wait.
• Si contiene “401” o “403”, alerta inmediata porque hay un problema de credenciales.
• Para el resto, alerta estándar con prioridad normal.

Esto parece complicado de implementar pero con un Switch node en el error workflow y tres ramas, está hecho en 15 minutos. La diferencia en operaciones diarias es enorme: dejas de recibir alertas para errores transitorios que se resuelven solos, y los errores reales siguen llegando.

El caso real que lo justifica todo

Un freelance que usa n8n para automatizar el envío de facturas a clientes tuvo un workflow que enviaba facturas en PDF por email cada primer día de mes. El workflow funcionó bien durante cuatro meses.

En el quinto mes, el nodo de generación de PDF falló porque el servicio que usaba cambió sus endpoints. El workflow falló en silencio durante todo el día 1. El cliente que esperaba su factura para cerrar el mes no la recibió, mandó un email preguntando, y la situación fue incómoda.

Con un error workflow básico, habría recibido la alerta a las 00:01 del día 1, con el mensaje de error exacto, habría actualizado el endpoint en 10 minutos, y el cliente habría recibido su factura sin saber que algo estuvo mal.

El tiempo de implementar el error workflow: 20 minutos. El coste de no tenerlo: una relación con un cliente dañada y horas de gestión.

Por dónde empezar si tienes workflows en producción

Si ya tienes workflows activos sin error handling, el orden es este:

1. Crea el error workflow central primero. Un Error Trigger, un Set que construya el mensaje, un Telegram o email. Guárdalo.
2. Ve a cada workflow en producción, Settings, y selecciona ese error workflow. Cinco segundos por workflow.
3. Hecho. Ya tienes cobertura básica en todo lo que tienes activo.

Después, si quieres refinar (lógica de reintentos, clasificación de errores, log en base de datos), mejoras el error workflow central y aplica a todos automáticamente.

El error handling en n8n no es una característica avanzada. Es el mínimo necesario para tener workflows en producción de verdad. Sin él, no tienes automatizaciones — tienes procesos que funcionan hasta que no funcionan, y no sabes cuándo eso pasa.