Wait Node Deep Dive
Understanding temporal controls and delayed execution
The Wait node pauses workflow execution for a specified duration before continuing. This enables delayed follow-ups, rate limiting, and time-based automation patterns.
Overview
The Wait node is a non-side-effecting control flow node that:
- Pauses execution for a configurable duration
- Passes all input data through unchanged
- Supports durations from seconds to years
- Does not consume external resources while waiting
Configuration
| Parameter | Type | Required | Description |
|---|---|---|---|
| amount | number | Yes | The number of time units to wait |
| unit | enum | Yes | The time unit to apply |
Available Time Units
| Unit | Description | Example Use Case |
|---|---|---|
seconds | Very short delays | Rate limiting API calls |
minutes | Short delays | Brief pause between actions |
hours | Medium delays | Same-day follow-up |
days | Day-scale delays | Next-day follow-up |
weeks | Week-scale delays | Weekly check-in |
months | Month-scale delays | Quarterly review |
years | Long-term delays | Annual reminders |
Example Configuration
{
"amount": 24,
"unit": "hours"
}
This waits 24 hours before passing data to the next node.
Use Cases
1. Delayed Follow-Up
Send a follow-up message after a meeting:
[Meeting Ended] → [AI: Generate Summary] → [Send Summary]
│
[Wait: 24 hours]
│
[Send Follow-up]
Configuration:
- Amount: 24
- Unit: hours
2. Rate Limiting
Prevent overwhelming external APIs:
[Select Many: items] → [API Call] → [Wait: 1 second] → [Next Action]
Configuration:
- Amount: 1
- Unit: seconds
3. Cooling Period
Allow time for external systems to process:
[Create CRM Task] → [Wait: 5 minutes] → [Verify Task Created]
Configuration:
- Amount: 5
- Unit: minutes
4. Scheduled Reminder
Send reminders before deadlines:
[Deal Created] → [Wait: 7 days] → [If: deal still open?]
│
├── Yes → [Send Reminder]
│
└── No → [Sink]
Configuration:
- Amount: 7
- Unit: days
5. Weekly Check-In
Periodic follow-ups for ongoing deals:
[Deal Update] → [Send Update] → [Wait: 1 week] → [Check Deal Status]
Configuration:
- Amount: 1
- Unit: weeks
Data Flow
Input
The Wait node accepts any input from upstream nodes:
{{ json }} // All upstream data
Output
The Wait node passes input data through unchanged:
Input: { meeting: {...}, summary: "..." }
Output: { meeting: {...}, summary: "..." } // Same data
Per-Item Processing
In per-item mode, each item waits independently:
[Select Many: 3 items] → [Wait: 1 minute] → [Process]
All 3 items begin waiting at the same time and continue after 1 minute.
Workflow Patterns
Pattern 1: Graduated Follow-Up
Multiple follow-ups at increasing intervals:
[Initial Contact] → [Wait: 1 day] → [First Follow-up]
│
[Wait: 3 days]
│
[Second Follow-up]
│
[Wait: 1 week]
│
[Final Follow-up]
Pattern 2: Time-Gated Execution
Execute only if condition still true after delay:
[Trigger] → [Wait: 2 hours] → [Load Current State]
│
[If: condition still true?]
│
├── Yes → [Execute]
│
└── No → [Sink]
Pattern 3: Parallel Branches with Delays
Different delays on different branches:
[Trigger] ──┬──▶ [Wait: 1 hour] ──▶ [Send Email]
│
├──▶ [Wait: 1 day] ───▶ [Send SMS]
│
└──▶ [Immediate Action]
Pattern 4: Retry with Backoff
Manual retry pattern with increasing delays:
[Action] ──▶ [On Error] ──▶ [Wait: 1 minute] ──▶ [Retry Action]
│
[On Error]
│
[Wait: 5 minutes]
│
[Final Retry]
Implementation Details
How Waiting Works
- Execution State: The node records the wake-up time in execution state
- Scheduling: The system schedules the continuation
- Resume: At the scheduled time, execution resumes
- Data Passthrough: Original input is passed to output
Resource Usage
- No Active Resources: The wait doesn't consume compute resources
- State Storage: Minimal state stored (wake-up time)
- Reliable Delivery: Continuation is guaranteed even after system restarts
Precision
| Unit | Typical Precision |
|---|---|
| seconds | ± few seconds |
| minutes | ± 1 minute |
| hours | ± few minutes |
| days | ± few minutes |
| weeks/months/years | ± few minutes |
Wait durations are best-effort. Very short waits (< 30 seconds) may have more variance.
Best Practices
1. Use Appropriate Granularity
Match the unit to your use case:
❌ Awkward:
{ "amount": 1440, "unit": "minutes" } // 24 hours in minutes
✅ Clear:
{ "amount": 1, "unit": "days" }
2. Consider Business Hours
For customer-facing actions, consider when the message will arrive:
[Wait: 24 hours] → [If: is business hours?] → [Send]
│
└── No → [Wait: until morning] → [Send]
3. Verify State After Long Waits
After long delays, conditions may have changed:
[Wait: 1 week] → [Load Current Deal State] → [If: still relevant?]
│
└── Yes → [Action]
4. Use Wait for Rate Limiting
When processing many items, add waits to prevent API throttling:
[Select Many: items] → [API Call] → [Wait: 500 ms] → [Next]
5. Document Long Waits
When using long waits, consider adding notes:
// Wait 30 days for contract review period
[Wait: 30 days]
Common Issues
Issue: Wait Seems Too Short
Cause: System load or scheduling variance.
Solution: For critical timing, build in buffer time or verify conditions after wait.
Issue: Workflow Appears Stuck
Cause: Long wait in progress.
Solution: Check execution status to see wait end time. The workflow is working correctly.
Issue: Multiple Waits Not Working
Cause: Waits on parallel branches start at the same time.
Solution: This is expected behavior. Each branch waits independently from when it starts.
Comparison with Scheduling
| Feature | Wait Node | Scheduled Trigger |
|---|---|---|
| Purpose | Pause within workflow | Start workflow at time |
| Precision | Duration-based | Clock-time based |
| Use Case | Delays, rate limiting | Daily reports, recurring tasks |
| Start Point | After previous node | Beginning of workflow |