Wait Until: Programar Acciones Futuras

Descripción de la cápsula

Wait Until pausa hasta un timestamp absoluto. Útil cuando sabes la fecha/hora exacta (cumpleaños del cliente, día de evento, hora específica de campaña).

Lo que vas a aprender

✅ Configurar Wait Until con expressions dinámicas
✅ Manejar timezones correctamente
✅ Casos típicos de scheduling per-item

Configuración

Wait node con:

Mode: Wait Until
Until: timestamp ISO o expression

Expression dinámica

// 3 días desde ahora
{{ DateTime.now().plus({ days: 3 }).toISO() }}

// Una hora antes de la cita del cliente
{{ DateTime.fromISO($json.appointment_date).minus({ hours: 1 }).toISO() }}

// El próximo lunes 9am
{{ DateTime.now().setZone('America/Mexico_City').plus({ weeks: 1 }).set({ weekday: 1, hour: 9, minute: 0 }).toISO() }}

Casos típicos

Caso 1: Recordatorio antes de evento

[Trigger: nueva reservación]
   │
[Wait Until: $json.date - 24 horas]
   │
[Send Email: recordatorio]

Cada reservación tiene su propia ejecución que despierta 24h antes de la fecha.

Caso 2: Cumpleaños

[Trigger: cliente nuevo]
   │
[Set: fecha del próximo cumpleaños]
   │
[Wait Until: próximo cumpleaños]
   │
[Send Email: feliz cumpleaños + descuento]
   │
[Wait Until: siguiente cumpleaños (+ 1 año)]
   │
... loop

(Loop infinito — un workflow por cliente que vive años.)

Realmente este caso es mejor con Schedule diario que filtra cumpleaños de hoy. Wait Until per-customer escala mal.

Caso 3: Lanzamiento de campaña

[Manual Trigger]
   │
[Sheet: leer suscriptores]
   │
[Wait Until: 2026-06-01T09:00:00 CDMX]
   │
[Send Email: campaña]

Workflow se "arma" pero espera al día específico.

Caso 4: Trial expiration

[Trigger: nuevo trial]
   │
[Wait Until: $json.signup_date + 14 días]
   │
[IF: usuario sigue activo y no upgrade?]
└─ TRUE → [Send Email: "tu trial vence mañana"]

Wait Until con timezone

// 9am CDMX el próximo lunes
{{
  DateTime.now()
    .setZone('America/Mexico_City')
    .plus({ weeks: 1 })
    .set({ weekday: 1, hour: 9, minute: 0, second: 0 })
    .toISO()
}}

.setZone() convierte a CDMX. .set() ajusta a 9am lunes. .toISO() produce timestamp con offset apropiado.

Limitaciones

Wait muy lejos en el futuro

Wait hasta dentro de años es teóricamente posible pero arriesgado:

n8n versions cambian
Plan limits
Servidor outages

Mejor: usar Schedule alternativo (cápsula 03) para waits de meses+.

Cambios en datos durante el Wait

Si el workflow espera 30 días, los datos pineados al inicio están outdated al despertar.

Solución: al despertar, re-leer datos críticos antes de actuar.

[Wait Until: 30 días]
   │
[HTTP: leer estado actual del cliente]  ← refresh
   │
[procesamiento con datos frescos]

Trampas comunes

Trampa 1: Wait Until con timestamp pasado

Qué pasa: Wait Until a 2026-05-01 cuando hoy es 2026-05-11. Timestamp es pasado.

Comportamiento: depende de versión — algunos n8n ejecutan inmediatamente, otros lanzan error.

Cómo evitar: Validar que el timestamp es futuro antes del Wait:

[IF: $json.timestamp > $now]
├─ TRUE → continuar con Wait
└─ FALSE → skip / log "fecha pasada"

Trampa 2: Timezone implícita

(Cubierto en cápsula 02 también.) Siempre explícita la timezone.

Trampa 3: Workflow vive mucho tiempo

Wait Until de 1 año → execution en estado "Waiting" 1 año. Si abres Executions panel, ves 1000s de waiting executions.

Cómo evitar: Wait Until largos = considerar Schedule alternativo. Más limpio.

Trampa 4: Olvidar refresh de datos

Qué pasa: Wait 30 días. Workflow al despertar usa datos pineados del inicio. Datos están viejos.

Cómo evitar: Re-leer estado crítico después del Wait.

Resumen

Wait Until: pausa hasta timestamp absoluto
Configurar con expressions dinámicas (Luxon)
Timezone awareness crítica
Casos: recordatorios, cumpleaños, lanzamientos, expiraciones
Limitaciones: waits muy largos mejor con Schedule alternativo
4 trampas: timestamp pasado, timezone implícita, workflow vive mucho, sin refresh

Lo que sigue: Resume Webhook — workflows que continúan cuando llega un evento externo.

Creado: Mayo 11, 2026 Versión: 1.0