Módulo 7: Wait Nodes y Flujos Asíncronos

Workflows de larga duración

Siguiente →

Descripción de la cápsula

Workflows que viven horas, días, o semanas tienen consideraciones especiales: outages del servidor, datos que cambian durante el Wait, observabilidad, mantenibilidad. Esta cápsula cubre los factores a considerar antes de diseñar long-running workflows.

Lo que vas a aprender

  • ✅ Riesgos de workflows largos
  • ✅ Cuándo long-running es la opción correcta vs alternativas
  • ✅ Patterns para hacerlos robustos

Riesgos

Riesgo 1: Server restart

n8n se reinicia (deploy, mantenimiento, crash). Workflows en Wait...

  • n8n versiones modernas: persisten estado, reanudan después
  • Versiones viejas o configuraciones específicas: pueden perderse

Verificar comportamiento de tu versión antes de confiar.

Riesgo 2: Datos obsoletos

Workflow espera 7 días. Al despertar, los datos que pineó/cacheó están viejos.

Solución: refresh data al despertar (cápsula 04).

Riesgo 3: Lógica obsoleta

Workflow espera 30 días. En esos 30 días tú modificaste el workflow. ¿Cuál versión ejecuta al despertar?

  • Depende de versión de n8n
  • Comúnmente: la versión actual del workflow, no la que estaba al iniciar
  • Implicación: cambios pueden romper executions en flight

Riesgo 4: Plan limits

Cloud plans tienen limit de "running executions". Workflows en Wait cuentan.

Riesgo 5: Observabilidad

Workflow vive 30 días. ¿Cómo sabes que está sano? ¿Cuántos están en cada paso?

Solución: logging + dashboard.

Cuándo long-running es correcto

Sí

  • Acciones espaciadas en tiempo (drip campaigns 7-14 días)
  • Esperar callbacks de servicios externos
  • Aprobaciones humanas con timeout corto-medio (horas-días)

No

  • Acciones que se pueden hacer con Schedule recurrente (cápsula 03)
  • Volúmenes altos (1000s de workflows en Wait → caos)
  • Cuando la lógica cambia frecuentemente

Alternativa: Schedule + State

Para muchos casos, Schedule recurrente + estado en DB/Sheet es más robusto que long-running.

Long-running

[Webhook] → ... → [Wait 7 days] → [Action]

Cada signup crea un workflow que vive 7 días.

Schedule + State

Workflow A: capturar
[Webhook] → [Sheet append: signup con fecha]

Workflow B: process diario
[Schedule diario]
   │
[Sheet read: signups]
   │
[Filter: days_since_signup === 7]
   │
[Action]

Workflow B ejecuta diariamente, procesa los que cumplen el día. Mucho más robusto:

  • Sin Wait largo
  • Estado persistente en Sheet
  • Lógica fácil de cambiar (cambias workflow B una vez)
  • Recovery si algo falla (mañana lo intenta de nuevo)

Patterns para long-running robusto

Pattern 1: Checkpoint logging

Cada paso significativo del workflow long-running, log en Sheet:

[step 1] → [Sheet: log "step1 done"]
   │
[Wait]
   │
[step 2] → [Sheet: log "step2 done"]

Si algo falla, ves dónde quedó. Análisis post-hoc.

Pattern 2: Refresh after wait

Después de cada Wait, refrescar datos críticos:

[Wait Until: ...]
   │
[HTTP: re-fetch estado del recurso]
   │
[IF: ¿sigue siendo válido procesar?]
└─ ...

Pattern 3: Cancelability

Permitir cancelar workflows en flight:

[Each step]
   │
[Sheet: check 'cancellations' for this execution_id]
   │
[IF: cancelado?]
└─ TRUE → terminar workflow

Un workflow paralelo o admin puede agregar a cancellations para parar workflows in-flight.

Pattern 4: Versioning de lógica

Si tu workflow long-running puede cambiar entre executions:

  • Stampear versión al iniciar: workflow_version: 1.2
  • Al despertar, IF según versión
  • Permite executions viejos seguir lógica vieja

Avanzado. Generalmente preferir Schedule + State.

Diagnóstico de long-running

Si tienes workflows long-running activos, métricas útiles:

  • Count de waiting executions: muchos → potential issue
  • Edad de waiting más vieja: ¿algo se quedó colgado?
  • Tasa de completion exitosa: % de iniciados que terminan OK

Dashboard manual con Sheet + métricas calculadas, o herramientas profesionales.

Trampas comunes

Trampa 1: Long-running para drip cuando Schedule es mejor

Qué pasa: Drip 14 días con Wait. Tienes 1000 leads → 1000 workflows en Wait. Caos.

Cómo evitar: Schedule diario con Sheet de leads + filter por días.

Trampa 2: Cambiar workflow mientras hay executions in-flight

Qué pasa: Hay 100 executions en Wait. Modificas el workflow. Comportamiento al despertar inesperado.

Cómo evitar:

  • Verificar count de waiting antes de modificar
  • Esperar a que terminen, o
  • Cancelarlos explícitamente antes del cambio

Trampa 3: Asumir que servidor nunca cae

Qué pasa: Servidor n8n cae. Workflows en Wait pierden estado (en algunas configs).

Cómo evitar: Para casos críticos, estado persistente externo (Sheet/DB), no solo Wait.

Trampa 4: Sin observabilidad

Qué pasa: Tienes 500 workflows long-running. No sabes cuántos están en cada paso. No sabes si algo está roto.

Cómo evitar: Logging + métricas. Dashboards.

Resumen

  • Long-running = workflows que viven horas/días/semanas
  • Riesgos: server restart, datos obsoletos, lógica obsoleta, plan limits, observabilidad
  • Alternativa preferible: Schedule + State en Sheet/DB
  • Patterns robustos: checkpoint logging, refresh after wait, cancelability, versioning
  • 4 trampas: long-running cuando Schedule es mejor, modificar mid-flight, asumir servidor, sin observabilidad

Lo que sigue: Mini-proyecto integrador.

Creado: Mayo 11, 2026 Versión: 1.0

← AnteriorHuman-in-the-Loop (intervención humana)Siguiente →Mini-Proyecto: Workflow con Espera y Aprobación