Wait Node

The Wait node pauses the workflow for a set amount of time, then passes its input through unchanged. Use it to space out actions, respect rate limits, or line up a step with a specific moment.

Overview

A Wait node introduces a deliberate delay between steps. While it waits, nothing downstream runs; once the wait is over, the data it received flows on exactly as it arrived.

• Space out a series of calls so you stay under a service's rate limit
• Pause between a "created" step and a "follow-up" step
• Hold a branch until a particular date or time
• Add a short breather between retries

How It Works

The node has two modes.

Duration

Wait a fixed length of time, then continue:

• Choose an amount and a unit — seconds, minutes, or hours
• The workflow resumes as soon as the time elapses

Send first message → Wait (30 seconds) → Send follow-up

Until

Wait until a specific date and time, then continue:

• Pick the moment to resume
• If that moment is already in the past when the node runs, it continues immediately

Prepare announcement → Wait (until 9:00 AM) → Publish

Input Passes Through Unchanged

The Wait node does not modify your data. Whatever it receives is exactly what the next node receives — it only adds a pause in between. This makes it safe to drop into the middle of an existing flow without rewiring or reshaping data.

{ "orderId": 1234, "email": "a@example.com" }
        │
     Wait (1 minute)
        │
{ "orderId": 1234, "email": "a@example.com" }   ← identical

Common Patterns

Rate Limiting

When a downstream service limits how often you can call it, place a Wait inside a loop so each iteration pauses before the next call:

Loop (each recipient)
├── Send request
└── Wait (2 seconds)

Staged Timing

Drip out a sequence with gaps between each step:

Welcome message → Wait (1 hour) → Tips message → Wait (1 hour) → Survey

Scheduled Resume

Hold a branch until a fixed time using Until mode, so the rest of the flow only runs at the moment you want.

Limits

Waits run while the workflow is active and are capped at a few minutes per node in the current release. Very long waits, or waits that need to survive a restart, are planned for a future update. For long delays today, prefer a scheduled trigger that starts the later part of the work as its own run.

Best Practices

1. Keep durations short — current waits are best for seconds-to-minutes spacing, not multi-hour pauses.
2. Place Wait inside loops for rate limiting so every iteration is spaced, not just the first.
3. Remember input is untouched — you don't need to re-map data after a Wait.
4. Use a scheduled trigger instead of a long Wait when you need a delay measured in hours or days.

Related Topics

• Loop Node - Add a Wait inside a loop to pace each iteration
• Triggers & Scheduling - Start work at a set time instead of waiting in-flow
• Set Variable Node - Remember a value across the pause
• Condition Node - Decide whether a wait is needed