> ## 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.
# Wait step
> Pause execution for a set duration before continuing.
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.
## Inspector
The Wait step inspector has a single **Duration** field:
* A number input (default: `1`)
* A unit dropdown: **Minutes**, Hours, Seconds, Days
Set the duration and click **Save**.
## 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. |
For agent tool workflows (which run synchronously during a live call), keep Wait durations very short or remove them entirely. The user is waiting on the line.
## What lands in ctx
After the wait completes:
```json theme={null}
{
"Wait": {
"waited_seconds": 900
}
}
```
## 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](/workflows/triggers/scheduled) for recurring scheduled jobs instead of a long-running workflow with internal Waits.