# Wait (/workflows/blocks/wait)





The **Wait block** delays the next step. Choose an inline wait for seconds or a few minutes, or enable **Async** to suspend the run and resume later.

<BlockPreview type="wait" />

## Space out requests [#space-out-requests]

<WorkflowPreview workflow="WAIT_RATELIMIT_WORKFLOW" />

A two-second wait spaces the two API requests apart. It can also sit between polling attempts. Account for other branches and workflow runs when calculating an API's rate limit.

## Configuration [#configuration]

| Field | Behavior |
| - | - |
| **Wait Amount** | Positive duration. Defaults to `10`. |
| **Unit** | **Seconds** or **Minutes** with Async off; **Minutes**, **Hours**, or **Days** with Async on. |
| **Async** | Off: wait in the running execution, up to 5 minutes. On: suspend and schedule resumption, up to 30 days. |

Async always suspends the run, even for a short duration. The resume poller picks it up after the scheduled time, so `resumeAt` is not an exact execution-time guarantee. Self-hosted deployments need their [resume scheduler](/platform/self-hosting/background-jobs) configured for automatic resumption.

## Outputs [#outputs]

| Reference | Value |
| - | - |
| `<wait.status>` | `waiting` for a suspended wait, `completed` for a finished inline wait, or `cancelled` when an inline wait is interrupted |
| `<wait.waitDuration>` | Requested duration in milliseconds |
| `<wait.resumeAt>` | Scheduled ISO resume timestamp for an async wait |

Stopping a run cancels an active wait. A delay extends the workflow's wall-clock completion time; log duration and resumed execution records describe execution separately.

## Send a delayed follow-up [#send-a-delayed-follow-up]

<WorkflowPreview workflow="WAIT_FOLLOWUP_WORKFLOW" />

Enable Async and select two days to suspend the run before the follow-up step. Configure that step's messaging tool to send the notification.

## Related docs [#related-docs]

* [API](/workflows/blocks/api)
* [Human in the loop](/workflows/blocks/human-in-the-loop)