⏱ Wait
Pauses workflow execution for a fixed number of seconds before continuing to the next step.
Useful for rate limiting, pacing API calls, and giving external systems time to process.
Category: Flow Control · Type identifier: wait
Overview
The Wait node introduces a deliberate pause in your workflow. When execution reaches it,
Flusso holds the run for the number of seconds you specify and then resumes with the next
step exactly as if nothing happened. All variables and step outputs from before the pause are
still available afterwards.
Common use cases include:
- Rate limiting. Many third-party APIs allow only a certain number of
requests per second. Placing a Wait node inside a Loop adds a delay between each iteration
to stay within limits.
- Waiting for external processing. After triggering an asynchronous job
on an external system, wait a few seconds before polling for the result.
- Artificial pacing. In workflows that send a series of notifications,
a brief pause between messages can avoid spam filters and improve deliverability.
Long waits consume a queue worker. While a Wait node is pausing, the queue
worker handling that run is occupied. For waits longer than 60 seconds, consider restructuring
your workflow: use a Schedule Trigger on a follow-up workflow, or split the
work across two workflows connected by an event.
Configuration
| Field |
Status |
Description |
| Seconds |
Required |
The number of seconds to pause. Must be an integer between 1 and 3600. Supports {{ variable }} references if you need a dynamic delay. For example, {{ trigger.output.retry_delay }}. |
Output Data
| Variable |
Type |
Description |
waited_seconds |
integer |
The actual number of seconds the node waited. |
resumed_at |
string (ISO 8601) |
The UTC timestamp at which execution resumed, e.g. 2026-03-12T14:05:30Z. |
{{ wait_step.output.waited_seconds }}
{{ wait_step.output.resumed_at }}
Example Usage
Rate-limited API calls inside a loop
You are sending SMS messages via a gateway that allows a maximum of one message per second.
-
Add a Loop node iterating over {{ fetch.output.recipients }}.
-
Inside the loop, add an HTTP Request node that calls the SMS gateway with
{{ loop_step.current_item.phone }}.
-
After the HTTP Request, add a Wait node with Seconds set to 1.
This ensures the next iteration does not begin until at least one second has passed.
Poll for a result after triggering a slow job
-
HTTP Request node — POST to an external service to start a background job.
The response contains a job_id.
-
Wait node — pause for 10 seconds to give the job time to
complete.
-
HTTP Request node — GET the job status using
{{ start_job.output.job_id }}.
-
Logic Gate node — check if {{ poll_job.output.status }}
equals complete before continuing.
Tips & Notes
-
Keep waits short. The sweet spot is 1–10 seconds. Anything beyond a
minute should prompt you to reconsider whether a Wait is the right tool.
-
Dynamic seconds. If the delay varies by item or condition, store it in a
variable with a Set Variable node first, then reference
it in the Seconds field:
{{ delay_step.output.delay_seconds }}.
-
Waits survive worker restarts. If the queue worker restarts while a Wait
is active, the job will be re-queued. The wait will restart from zero, which may result in
a longer-than-expected pause. Design accordingly.
Related Nodes
- Loop — iterate over items; place a Wait inside to pace iterations.