The Wait step suspends execution for a configurable duration, then resumes at the next step. Use it to delay follow-up actions, implement cooldowns, or schedule work after a fixed interval.Documentation Index
Fetch the complete documentation index at: https://docs.anyreach.ai/llms.txt
Use this file to discover all available pages before exploring further.

Inspector
The Wait step inspector has a single Duration field:- A number input (default:
1) - A unit dropdown: Minutes, Hours, Seconds, Days
When to use it
| Use Wait when | Don’t use it when |
|---|---|
| Delaying a follow-up action (“send the SMS 15 minutes after the call”) | You need sub-second pacing — use time.sleep() in a Code step |
| Implementing a cooldown before retrying an API call | You want to block on an external event — Wait only pauses by time |
| Scheduling follow-up work after a fixed interval | You want periodic execution — use a Timer trigger instead |
Sync vs async behavior
| Execution mode | Behavior |
|---|---|
| Async | Workflow status flips to waiting. Worker resources are released. Execution resumes when the timer fires. |
| Sync | The request blocks until the timer fires, up to the sync timeout. Avoid long Wait durations in sync workflows. |
What lands in ctx
After the wait completes:Considerations
- Durations are from when the Wait step is reached, not from when the workflow started. Upstream step latency doesn’t shift the timer.
- Check state after waiting. The real-world situation may have changed during the wait (e.g., the contact already replied). Verify current state in the next step rather than assuming nothing changed.
- Don’t use Wait for periodic execution. Use a Timer trigger for recurring scheduled jobs instead of a long-running workflow with internal Waits.

