Manejo de errores en N8N: reintentos, alertas y flujos de error

Toda automatización fallará algún día. Una API se cae, una credencial expira, un cliente completa un campo de forma inesperada. El problema no es el fallo en sí, sino descubrir días después que un proceso importante se detuvo sin avisar a nadie. En este artículo veremos las herramientas que N8N ofrece para manejar errores y cómo combinarlas en una estrategia simple.

Por qué manejar errores desde el principio

Un workflow sin manejo de errores funciona bien mientras todo sale bien. Cuando algo falla, la ejecución se detiene en el nodo con problemas y el resto del flujo no ocurre. Si nadie revisa la lista de ejecuciones, el fallo pasa desapercibido.

Manejar errores desde el principio trae tres beneficios:

• Los fallos temporales se resuelven solos, sin intervención.
• Los fallos permanentes llegan a quien puede resolverlos, en el momento en que ocurren.
• Los datos que no pudieron procesarse quedan registrados para un nuevo intento.

Tipos de error más comunes

Tipo	Ejemplo	Mejor respuesta
Temporal	Tiempo agotado, límite de solicitudes, inestabilidad	Intentar de nuevo tras unos segundos
De datos	Campo vacío, formato inválido, registro inexistente	Desviar el ítem y registrar el motivo
De configuración	Credencial expirada, permiso denegado	Alertar al equipo de inmediato

Separar los errores por tipo ayuda a elegir la herramienta adecuada para cada uno.

Reintentos automáticos

En la configuración de cada nodo existe la opción Retry On Fail. Al activarla, defines cuántos intentos debe hacer N8N y cuánto esperar entre ellos.

Es ideal para llamadas HTTP e integraciones con servicios externos, donde la mayoría de los fallos son pasajeros. Una configuración común es de tres intentos con unos segundos de intervalo. Para APIs con límite de solicitudes, aumenta el intervalo para dar tiempo a que el límite se reinicie.

Los reintentos no resuelven errores de datos o de configuración. Repetir una llamada con una credencial expirada solo retrasa la alerta.

Continuar el flujo cuando un nodo falla

También en la configuración del nodo, la opción On Error define qué ocurre cuando se agotan los intentos:

1. Detener el workflow: el comportamiento predeterminado. La ejecución termina con error.
2. Continuar: el flujo sigue con los datos que el nodo logró producir, ignorando el fallo.
3. Continuar usando la salida de error: el nodo obtiene una segunda salida, por donde pasan solo los ítems que fallaron.

La tercera opción es la más útil para errores de datos. Los ítems válidos siguen el camino normal, mientras que los problemáticos van a una rama separada, donde pueden guardarse en una hoja de pendientes o enviarse a revisión.

El workflow de error

Para fallos que interrumpen la ejecución, N8N permite definir un workflow de error. Es un flujo separado que empieza con el nodo Error Trigger y se ejecuta automáticamente cada vez que otro workflow falla.

Para configurarlo:

1. Crea un nuevo workflow con el nodo Error Trigger como disparador.
2. Agrega los nodos que deben avisar al equipo, como correo, Slack, Telegram o WhatsApp.
3. En la configuración del workflow que quieres proteger, elige ese flujo en el campo de workflow de error.

El Error Trigger recibe el nombre del workflow que falló, el nodo donde ocurrió el error, el mensaje de error y el enlace a la ejecución. Así, la alerta llega con todo lo necesario para investigar.

Un único workflow de error puede atender a todos tus flujos. Así, las alertas quedan estandarizadas y mantienes todo en un solo lugar.

Generar errores a propósito

A veces el flujo no falla técnicamente, pero el resultado es incorrecto. Una consulta que debería devolver un cliente vuelve vacía, o un valor llega negativo.

Para esos casos, usa el nodo Stop and Error. Interrumpe la ejecución con un mensaje definido por ti y activa el workflow de error como cualquier otro fallo. Es la forma de convertir una regla de negocio en una alerta.

Buenas prácticas para alertas

• Envía las alertas a un canal que el equipo realmente sigue.
• Incluye el enlace de la ejecución, el nombre del flujo y el mensaje de error.
• Evita alertas para fallos que ya se resuelven con reintentos.
• Agrupa los fallos repetidos para no generar decenas de mensajes iguales.
• Revisa las ejecuciones con error cada semana, aunque nada haya parecido urgente.

Una estrategia simple para empezar

Si todavía no manejas errores, empieza por estos tres pasos:

1. Activa los reintentos en todos los nodos que llaman a servicios externos.
2. Crea un workflow de error con una alerta para el canal del equipo y vincúlalo a los flujos más importantes.
3. Usa la salida de error en los nodos que procesan datos provenientes de personas, como formularios y hojas de cálculo.

Estos pasos llevan menos de una hora y eliminan la mayor parte de los fallos silenciosos.

La infraestructura también cuenta

El manejo de errores cubre lo que ocurre dentro de los flujos. Pero si la instancia de N8N se cae, ningún workflow de error se ejecutará.

Con lui, cada cliente tiene una instancia dedicada de N8N, aislada de las demás y acompañada por nuestro equipo. Así, tú cuidas las reglas de tus flujos y lui cuida la infraestructura que los mantiene en funcionamiento.

Conclusión

Las automatizaciones confiables no son las que nunca fallan, sino las que fallan de forma visible y se recuperan solas cuando es posible. Combinando reintentos, salidas de error, un workflow de error y alertas bien pensadas, te aseguras de que ningún proceso importante se detenga en silencio.