Módulo 6: Ejecuciones y Debugging

Retry y Error Handling Básico

Descripción de la cápsula

Hasta acá has aprendido a diagnosticar errores después de que pasan. Esta cápsula va al otro lado del tiempo: cómo configurar tus workflows para que no se rompan cuando hay errores predecibles. Hay 3 técnicas principales, ordenadas de más simple a más sofisticada: Retry on failure (un nodo reintenta solo si falla), Continue on fail (el workflow sigue aunque un nodo falle), y Error Trigger (un workflow paralelo se dispara cuando otro falla, para notificarte).

Sin estas técnicas, cualquier hiccup transitorio (un timeout de red, un 503 momentáneo, un rate limit pasajero) detiene completamente tu workflow. Con estas técnicas, un workflow profesional sobrevive a errores transitorios sin intervención humana y te alerta solo cuando hay algo que realmente requiere atención.

No es ingeniería avanzada — son 3 toggles y 1 patrón. Pero hacen la diferencia entre "workflow de demo" y "workflow de producción confiable".

Lo que vas a aprender

Al terminar esta cápsula serás capaz de:

✅ Configurar Retry on failure con intervalo y número de intentos
✅ Decidir cuándo retry y cuándo no según el tipo de error
✅ Usar Continue on fail para que un nodo fallido no detenga el workflow
✅ Configurar un Error Trigger que se dispara cuando otro workflow falla
✅ Construir un workflow de notificación de errores con Slack/Email
✅ Aplicar el patrón completo a un workflow productivo

Técnica 1: Retry on failure

Qué es

n8n te permite configurar que un nodo específico reintente automáticamente si falla. Útil para errores transitorios (red, rate limit corto, 503 momentáneo).

Cómo configurarlo

Abre el nodo en el editor
Click en la pestaña Settings del nodo (engranaje en la parte superior, o tab "Settings")
Activa toggle Retry On Fail
Configura:
- Max Tries: cuántos intentos en total (default: 3, máximo recomendado: 5)
- Wait Between Tries (ms): cuánto esperar entre intentos en milisegundos (default: 1000 = 1 segundo)

Cuándo retry SÍ tiene sentido

APIs externas con 503/504 ocasionales: un retry después de 2-5 segundos suele funcionar
Rate limits cortos: 429 con retry-after de unos pocos segundos
Timeouts intermitentes: red flaky
Llamadas a OpenAI/Anthropic que ocasionalmente fallan por carga del servicio

Cuándo retry NO tiene sentido

Errores de autenticación (401, 403): la credencial no se va a arreglar sola
Errores de configuración (400, 404): el dato o config malo no cambia
Errores de datos (campo undefined): retry da el mismo error
Rate limits largos: si el reset es en 1 hora, 3 retries de 1 segundo no ayudan

Principio: retry es útil cuando el error es transitorio (se resuelve solo). No es útil cuando el error es estructural (algo está mal y necesita intervención).

Estrategia de wait time

Tipo de error	Wait Between Tries
Red intermitente	1000-2000 ms (1-2 seg)
Rate limit corto	5000-10000 ms (5-10 seg)
API caída (503)	15000-30000 ms (15-30 seg)
Servicios lentos	30000+ ms

Si no sabes: default de 1000 ms y 3 tries está bien para empezar.

Exponential backoff (estrategia más robusta)

n8n por default usa wait time fijo entre tries. Para producción más robusta, querrías wait time creciente (1s, 2s, 4s, 8s...) — esto se llama exponential backoff y reduce el riesgo de saturar el servicio caído.

Para implementar backoff en n8n:

Para hosts críticos, agregar un nodo Wait entre el nodo principal y un nodo Code que verifica si reintentar
O usar la opción de retry con tiempos largos (más simple)
Versiones recientes de n8n (2026) están agregando backoff nativo — verifica tu versión

Técnica 2: Continue On Fail

Qué es

Si un nodo falla a pesar de los retries, normalmente el workflow se detiene. Continue on fail te permite decir "si este nodo falla, sigue de todos modos y déjame manejar el error después".

Cómo configurarlo

Abre el nodo → Settings
Activa Continue On Fail (o On Error: Continue)

Cuando el nodo falla, en lugar de detener el workflow, el nodo produce un output con un campo error en cada item, y el siguiente nodo se ejecuta.

Cuándo es útil

Caso 1: Operaciones por lote donde algunos pueden fallar

Procesas 100 leads del Sheet, mandas email a cada uno. Si el email de uno falla (dirección malformada), no quieres que se detenga el envío para los otros 99.

Solución: Continue on Fail en el Send Email node. Los 99 emails buenos salen, el 1 fallido queda registrado.

Caso 2: Operaciones "best effort"

Tu workflow principal debe terminar siempre. Como extra, intenta notificar a un canal de Slack — pero si Slack está caído, no quieres detener el workflow.

Solución: Continue on Fail en el Slack node.

Caso 3: Diagnóstico de problemas

Quieres ver todos los errores de un batch sin que el workflow se detenga al primero. Continue on fail te deja ver el panorama completo.

Cómo detectar items que fallaron (después de continue on fail)

Cuando un nodo con Continue on Fail falla en algún item:

En el Output de ese nodo, los items que fallaron tienen un campo error con el detalle
Los items exitosos siguen normal

Puedes agregar un IF node después que separa items con $json.error (fallidos) de los demás. Manejas cada rama distinto: notificas los fallidos, sigues con los exitosos.

Técnica 3: Error Trigger (workflow de notificación de errores)

Qué es

Un Error Trigger es un nodo de inicio especial que se dispara cuando otro workflow falla. Te permite tener un "workflow guardián" que se ejecuta automáticamente cuando algo falla, para notificarte por Slack/email/lo que quieras.

Por qué importa

Sin esto: si un workflow productivo falla, lo descubres cuando alguien se queja ("no me llegó el email de bienvenida"), o cuando revisas Executions manualmente (cápsula 02).

Con esto: te llega un Slack inmediato al canal de ops con "El workflow X falló en el nodo Y con error Z". Reaccionas en minutos en vez de días.

Cómo configurarlo

Paso 1: Crear el workflow de error handling

Crear nuevo workflow → llámalo [GUARDIAN] Error Notifier
Primer nodo: Error Trigger (busca "Error" en el panel de triggers → elige "Error Trigger")
Después conecta los nodos de notificación que quieras:
- Slack: Send Message con detalle del error
- Send Email: notificación al admin

Paso 2: Configurar el mensaje con detalles del error

El Error Trigger te da datos sobre el workflow que falló. En el Slack node, usa expressions:

🚨 *Workflow falló*

*Nombre:* {{ $json.workflow.name }}
*ID Workflow:* {{ $json.workflow.id }}
*Nodo que falló:* {{ $json.execution.lastNodeExecuted }}
*Error:* {{ $json.execution.error.message }}
*Ejecución:* {{ $json.execution.url }}

_Hora:_ {{ $json.execution.startedAt }}

Los nombres de campo pueden variar entre versiones de n8n. Inspecciona el output del Error Trigger (cápsula 03) para confirmar los paths exactos en tu versión.

Paso 3: Activar el workflow guardián

Click en toggle Active = ON
Save

Paso 4: Asignarlo como "Error Workflow" a tus workflows productivos

Para cada workflow productivo que quieres monitorear:

Abrir el workflow → Settings (engranaje superior derecho)
Sección Error Workflow → elige [GUARDIAN] Error Notifier
Save

A partir de ahora, cuando ese workflow falle, se dispara el guardian automáticamente.

Tip: un solo guardián para todos los workflows

No necesitas crear un guardian por workflow. Un solo [GUARDIAN] Error Notifier puede manejar errores de los 10 workflows productivos que tengas. Solo asígnalo como Error Workflow a cada uno.

El patrón completo: workflow de producción resiliente

Combinando las 3 técnicas, así se ve un workflow productivo bien hecho:

[Trigger]
   │
[Operación crítica con Retry on Fail = ON, max 3 tries]
   │
[Operación secundaria con Continue on Fail = ON]
   │
[Resultado / notificación de éxito]


+ Assigned Error Workflow: [GUARDIAN] Error Notifier
  (se dispara solo si todo lo anterior falla a pesar de retry)

Resultado neto

Errores transitorios → resueltos por retry, nadie se entera
Errores en operaciones secundarias → workflow sigue, item fallido queda registrado
Errores reales que detienen todo → Slack al admin en segundos para reacción rápida

Eso es producción profesional. No es difícil — son 3 toggles + 1 workflow guardián.

Ejemplo concreto: `[PROY-M05] Leads → Slack` hecho resiliente

Toma el workflow del mini-proyecto de M05 y aplícale las 3 técnicas:

Configuración resultante

Nodo	Setting
Manual Trigger	(sin cambios)
Google Sheets	Retry on Fail: ON, max 3, wait 2000 ms
Slack Send Message	Retry on Fail: ON, max 3, wait 2000 ms; Continue On Fail: ON
Workflow Settings	Error Workflow: `[GUARDIAN] Error Notifier`

Comportamiento resultante

Si Google Sheets falla por red intermitente: reintenta 3 veces, probablemente funciona el segundo
Si Slack rate-limita en mensaje 7 de 10: ese mensaje reintenta, los otros 9 ya pasaron
Si Slack está caído entero: Continue on Fail evita que se detenga; los 10 items salen del nodo aunque con error; el workflow termina; Error Workflow se dispara y te avisa por email (porque Slack también está caído)
Si tu credencial Google se revocó: retry no ayuda, Continue on Fail no aplica, el workflow falla en Sheets; Error Workflow se dispara y te avisa

Es robusto sin ser complicado.

Trampas y errores comunes

Trampa 1: Retry para errores estructurales

Qué pasa: Configuras retry para un nodo con error 403 Forbidden. Reintenta 3 veces, todas fallan con el mismo error. Workflow tarda 5 segundos más en fallar.

Por qué se da: No diferenciaste error transitorio (resoluble por retry) de estructural (no).

Cómo evitar:

Activa retry conscientemente según tipo de error esperado
Para nodos con auth (Google, Slack), retry tiene sentido para errores 5xx pero no para 401/403

Trampa 2: Continue on Fail oculta problemas serios

Qué pasa: Continue on Fail está activo. Un nodo falla en cada ejecución pero nadie se da cuenta porque el workflow termina con "success". Pasa una semana, el cliente pregunta por qué no recibe emails. Descubres que llevan 7 días fallando silenciosamente.

Por qué se da: Continue on Fail no notifica. Es "seguir como si nada".

Cómo evitar:

Combina Continue on Fail con un IF node después que detecta items con error y notifica:
```
[Nodo con Continue on Fail] → [IF: $json.error existe] → [Slack alert]
```
O agrega monitoreo periódico de Executions para detectar workflows con muchos errores parciales

Trampa 3: Olvidar configurar Error Workflow

Qué pasa: Workflow productivo falla, no se entera nadie por días.

Por qué se da: Error Workflow no está configurado por default. Hay que hacerlo explícitamente para cada workflow.

Cómo evitar:

Hábito: al activar un workflow productivo, último paso es asignar Error Workflow
Trata "no tiene Error Workflow asignado" como "no listo para producción"

Trampa 4: El propio Error Workflow falla

Qué pasa: Tu Error Workflow usa Slack para notificar. Slack está caído. El Error Workflow falla también. ¿Quién te avisa de eso?

Por qué se da: Hiciste depender la notificación de un servicio que también puede caer.

Cómo evitar:

Notificar por 2 canales independientes: Slack + Email. Si uno falla, el otro sirve.
Mejor aún: un canal externo a tus servicios (ej: SMS via Twilio si es crítico)

Trampa 5: Retry con efectos secundarios duplicados

Qué pasa: Tu workflow POSTea a una API que crea un registro. La API responde con 502 después de crear el registro. Tu retry dispara → crea otro registro. Resultado: dos registros en lugar de uno.

Por qué se da: El error 502 no significa que la operación no se realizó — puede haber pasado pero la respuesta se perdió.

Cómo evitar:

Idempotencia: usar APIs que aceptan un idempotency_key (Stripe, por ejemplo) — el segundo POST con la misma key no crea duplicado
Para APIs sin idempotency: poner retry solo en lectura (GET), no en escritura (POST/PUT/DELETE)
O agregar lógica que verifique antes de crear (check first, then create)

Ejercicio: hacer resiliente un workflow

Objetivo: aplicar las 3 técnicas al workflow del mini-proyecto.

Tu tarea

Crea un workflow nuevo: [GUARDIAN] Error Notifier
- Error Trigger
- Slack node con mensaje de error formateado (usa expressions)
- Activa el workflow
Abre [PROY-M05] Leads → Slack
Aplica:
- Google Sheets: Retry on Fail = ON, 3 tries, wait 2000
- Slack: Retry on Fail = ON, 3 tries; Continue on Fail = ON
- Settings → Error Workflow = [GUARDIAN] Error Notifier
Prueba el escenario de fallo:
- Cambia temporalmente la credencial de Slack a una inválida (modifica el token)
- Ejecuta el workflow → debe fallar a pesar de retries
- Verifica que llega notificación del Error Trigger guardian
Restaura la credencial buena

Lo que aprendiste

Retry funciona para errores transitorios pero no para auth/config rotos
Continue on Fail evita que un nodo malo detenga todo
Error Workflow + Error Trigger te avisan automáticamente cuando algo falla
Las 3 técnicas combinadas hacen un workflow "production-grade"

Resumen y siguiente paso

Retry on Fail: reintenta un nodo automáticamente. Útil para transitorios (5xx, timeouts, rate limits cortos). NO sirve para errores estructurales (auth, config).
Continue on Fail: el workflow sigue aunque el nodo falle. Útil para batch operations y operaciones "best effort". Combinar con IF para detectar items fallidos.
Error Trigger + Error Workflow: workflow paralelo que se dispara cuando otro falla. Notifica via Slack/Email. Asigna a cada workflow productivo.
Patrón completo: Retry + Continue + Error Workflow = workflow resiliente listo para producción.
5 trampas: retry para errores estructurales, Continue oculta problemas, olvidar Error Workflow, dependencia única para notificar, retry con efectos secundarios duplicados.

Antes de avanzar deberías poder:

Configurar Retry on Fail con max tries y wait time
Decidir cuándo activar retry y cuándo no
Crear un Error Workflow con Error Trigger + notificación
Asignar Error Workflow a un workflow productivo

Lo que sigue (cápsula 07):

Tienes las herramientas para diagnosticar y prevenir. La cápsula 07 es una referencia rápida de los 10 problemas que vas a encontrar más seguido — síntoma → causa → solución, sin perder tiempo en explicaciones. Es para tener a mano cuando algo falle y necesites resolver rápido.

Recursos adicionales

Error Handling in n8n - Documentación oficial completa.
Error Trigger Node - Detalles del Error Trigger.
Resilient Workflows (n8n Blog) - Patrones avanzados.

Creado: Mayo 11, 2026 Versión: 1.0

← AnteriorDebugging Paso a Paso Siguiente →Top 10 Problemas Frecuentes (Referencia Rápida)

Retry y Error Handling Básico

Descripción de la cápsula

Lo que vas a aprender

Técnica 1: Retry on failure

Qué es

Cómo configurarlo

Cuándo retry SÍ tiene sentido

Cuándo retry NO tiene sentido

Estrategia de wait time

Exponential backoff (estrategia más robusta)

Técnica 2: Continue On Fail

Qué es

Cómo configurarlo

Cuándo es útil

Caso 1: Operaciones por lote donde algunos pueden fallar

Caso 2: Operaciones "best effort"

Caso 3: Diagnóstico de problemas

Cómo detectar items que fallaron (después de continue on fail)

Técnica 3: Error Trigger (workflow de notificación de errores)

Qué es

Por qué importa

Cómo configurarlo

Paso 1: Crear el workflow de error handling

Paso 2: Configurar el mensaje con detalles del error

Paso 3: Activar el workflow guardián

Paso 4: Asignarlo como "Error Workflow" a tus workflows productivos

Tip: un solo guardián para todos los workflows

El patrón completo: workflow de producción resiliente

Resultado neto

Ejemplo concreto: [PROY-M05] Leads → Slack hecho resiliente

Configuración resultante

Comportamiento resultante

Trampas y errores comunes

Trampa 1: Retry para errores estructurales

Trampa 2: Continue on Fail oculta problemas serios

Trampa 3: Olvidar configurar Error Workflow

Trampa 4: El propio Error Workflow falla

Trampa 5: Retry con efectos secundarios duplicados

Ejercicio: hacer resiliente un workflow

Tu tarea

Lo que aprendiste

Resumen y siguiente paso

Recursos adicionales

Ejemplo concreto: `[PROY-M05] Leads → Slack` hecho resiliente