Módulo 6: Manejo de Errores

Rutas de respaldo (fallback)

Siguiente →

Descripción de la cápsula

Cuando algo crítico falla, ¿el workflow termina o intenta una alternativa? Fallback paths son las "rutas alternativas" que ejecuta tu workflow cuando la opción principal falla. Diferencia entre "workflow se rompe" y "workflow degrada elegantemente".

En esta cápsula vas a aprender los 3 patterns de fallback (alternative service, cached/default data, manual intervention), cuándo cada uno aplica, y cómo diseñarlos.

Lo que vas a aprender

  • ✅ Diseñar fallback paths efectivos
  • ✅ 3 patterns: alternative service, cached data, manual
  • ✅ Cuándo NO tener fallback (preferir falla loud)
  • ✅ Implementar en n8n

El concepto

Producción tiene SLAs. "El servicio enviar emails debe funcionar 99% del tiempo". Si tu workflow falla porque SMTP cayó, no llegas al SLA.

Fallback dice: "si SMTP falla, intenta con otro provider". Workflow sigue funcionando aunque el principal esté caído. SLA cumplido.

Pattern 1: Alternative service

Cuando el provider primario falla, usar el secundario.

[Trigger]
   │
[HTTP: provider A (Stripe)] con Continue on Fail
   │
[IF: error?]
├─ TRUE → [HTTP: provider B (PayPal)] (fallback)
│         [Sheet: log "fallback used for Stripe"]
│         continue
└─ FALSE → continue normal

Casos típicos

  • SMTP fallback: SendGrid → fallback a SES
  • AI provider: OpenAI → fallback a Anthropic
  • CRM: HubSpot → fallback a Sheet temporal
  • Storage: S3 → fallback a Drive

Cuándo no aplica

  • Servicios sin equivalente (provider único)
  • Cuando fallback es más caro y no vale la pena
  • Cuando provider primario debería ser confiable

Pattern 2: Cached / default data

Cuando una fuente de datos crítica falla, usar versión cached o defaults.

[HTTP: get latest config] con Continue on Fail
   │
[IF: error?]
├─ TRUE → [Sheet: leer última config exitosa cacheada]
│         continue con cache
└─ FALSE → [Sheet: write nueva config como cache]
           continue con datos frescos

Casos típicos

  • Pricing dinámico: si pricing API falla, usar pricing del Sheet (de hace 1 día)
  • User permissions: si IAM falla, usar permissions cacheados (con caveat de outdated)
  • Exchange rates: si API falla, usar rates del último día

Trade-off

  • Pros: workflow sigue funcionando
  • Contras: datos potencialmente outdated
  • Decisión: depende de cuán crítico es freshness vs availability

Pattern 3: Manual intervention queue

Cuando ningún fallback automático aplica, encolar para revisión humana.

[Operación crítica] con Continue on Fail
   │
[IF: error?]
├─ TRUE → [Sheet: append a 'requires_manual_review']
│         [Slack: "1 item requiere review manual"]
│         continue (sin procesar este item)
└─ FALSE → continue normal

Otro proceso (humano + workflow asistido) revisa la cola y procesa manualmente.

Casos típicos

  • Transacciones bancarias que no se pudieron auto-procesar
  • Identificación de cliente ambigua
  • Decisiones de compliance que requieren juicio humano

Cuándo NO usar fallback

Errores que indican bug

Si el error indica problema en tu workflow (no del servicio), fallback oculta el bug.

Mejor: que falle visible para que lo arregles.

Cuando fallback es peor que falla

Ejemplo: "si pagar con tarjeta falla, asumir que pagó". Eso es peor que reportar error.

Mejor: fallar y dejar al usuario reintentar.

Cuando aumenta complejidad sin valor proporcional

Workflow simple con 1 fallback: OK. Workflow con 5 niveles de fallback nested: difícil mantener.

Mejor: simplificar primario y aceptar que ocasionalmente falla.

Combinación: fallback + retry + alert

Patrón completo de resilience:

[Operación primary]
   ├─ Retry 3 veces con backoff
   ├─ Si falla los 3 → fallback secundario
   ├─ Si fallback también falla → log + alert + skip
   └─ Continúa workflow

3 niveles de defensa.

Implementación en n8n

Setup completo

[HTTP: provider primary]
  - Retry On Fail: 3 max, exponential backoff
  - Continue On Fail: ON
   │
[IF: $json.error existe?]
├─ TRUE → [HTTP: provider secondary] (fallback)
│         con Continue on Fail
│         │
│         [IF: secondary también falló?]
│         ├─ TRUE → [Sheet: append a 'manual_queue']
│         │         [Slack: alert]
│         │         → continuar workflow
│         └─ FALSE → continuar con result del secondary
│
└─ FALSE → continuar con result del primary

Caso completo: send email con fallback

[Send Email vía SendGrid] con Retry+Continue on Fail
   │
[IF: failed?]
├─ TRUE → [Send Email vía AWS SES] (fallback)
│         │
│         [IF: SES también failed?]
│         ├─ TRUE → [Sheet append a 'emails_failed']
│         │         [Slack alert: "Email a {email} no se pudo enviar"]
│         │         → continuar
│         └─ FALSE → log "SES used (SendGrid down)"
│
└─ FALSE → log success

Documentar fallbacks

Es crítico documentar los fallbacks:

  • Cuáles existen
  • Cuándo se activan
  • Qué consequencias tiene cada uno
  • Cómo monitorearlos

Sticky Note en el workflow

🔄 FALLBACK: si SendGrid falla, usa SES.
   SES tiene SLA distinto y rate limit más bajo.
   Si fallback activo > 10 veces/día, revisar.

Métricas a monitorear

Después de implementar fallbacks:

  • Tasa de uso del fallback: % de veces que se activa
  • Si tasa > 5%: problema con primary, investigar
  • Si tasa estable: OK, está funcionando como diseñado

Loggear en cada fallback usage en Sheet o métrica para análisis.

Trampas comunes

Trampa 1: Fallback sin notificación

Qué pasa: Fallback se usa todos los días. Workflow sigue funcionando. Nadie nota que primary está roto.

Cómo evitar: Notificar (silenciosamente OK) cada uso de fallback. Si frequency alta, alert.

Trampa 2: Fallback peor que primary

Qué pasa: Primary tiene rate limit 1000/min. Fallback tiene 10/min. Cuando primary falla, fallback se satura inmediatamente.

Cómo evitar: Fallback debe tener capacidad similar o mayor al primary.

Trampa 3: Fallback no testeado

Qué pasa: Configuras fallback. Nunca lo testeas. Primary cae. Fallback tiene un bug. Todo cae.

Cómo evitar:

  • Test el fallback intencionalmente (forzar primary a fallar)
  • Periódicamente (cada trimestre) test que sigue funcionando

Trampa 4: Demasiados niveles de fallback

Qué pasa: Primary → fallback1 → fallback2 → fallback3 → manual queue. Workflow imposible de entender.

Cómo evitar: Máximo 2 niveles + queue manual. Si necesitas más, simplificar arquitectura.

Resumen

  • Fallback paths: rutas alternativas cuando primary falla
  • 3 patterns: alternative service, cached data, manual queue
  • Combinar con retry y alert para defensa multinivel
  • NO usar cuando fallback oculta bugs, es peor que falla, o aumenta complejidad sin valor
  • Documentar y monitorear uso del fallback
  • 4 trampas: sin notificación, fallback peor, no testeado, demasiados niveles

Lo que sigue: Diseño defensivo — anticipar fallos antes de implementarlos.

Creado: Mayo 11, 2026 Versión: 1.0

← AnteriorError Workflow y Error TriggerSiguiente →Diseño Defensivo