Wait
The Wait step pauses a workflow and decides when it starts again. It can wait a fixed amount of time, wait until a particular date and time, or hold the run open until something outside Glow answers.
Find it under Flow in the Tools panel, or place it with the f then d shortcut.
A waiting run is not running. Glow puts the run down and picks it up when the wait is over. A step that waits two days costs no more than one that waits two seconds.
Setting it up
The first field is Wait Mode, and it changes every field below it. The four modes are:
| Wait Mode | Continues when |
|---|---|
| For a time interval | The amount of time you set has passed |
| Until a specific date and time | The clock reaches the date and time you set |
| On webhook call | Another system calls this run’s resume address |
| On form submitted | Somebody fills in a form and submits it |
The default is For a time interval.
For a time interval
Two fields: Amount and Unit. Amount defaults to 5, Unit offers Seconds, Minutes, Hours and Days. “Wait 2 days” is Amount 2, Unit Days.
Reach for this mode when you are spacing out calls to another service. It also suits giving a system a moment before you read back something you just wrote.
Until a specific date and time
Two fields: Resume at and Timezone.
Resume at takes a date and time like 2026-01-01 09:00. It also takes a reference to an earlier step, which is where most of its value is. A renewal date that arrived in the trigger becomes the moment the run continues:
{{ 2.renewalDate }}Timezone is the zone that date and time is read in. It defaults to the timezone of whoever built the workflow. Daylight saving is applied for the date being waited for rather than for today. A wait set now for a date in June gets June’s offset.
A value carrying its own offset (ending in Z, or +02:00) is read as an absolute moment. The Timezone field does not apply to it.
If the moment you name has already passed when the step runs, the workflow carries straight on rather than failing. “Wait until 09:00” evaluated at 09:05 continues immediately.
On webhook call
The run stops and waits for another system to call it. When the step runs, Glow mints a resume address that belongs to that one run, and publishes it on the step’s output as resumeUrl. Send it to whoever needs to call it back:
{{ 4.resumeUrl }}Put a step after the Wait that hands the address on. Two common shapes: an HTTP Request that registers it as a callback with a supplier’s API, or a Slack message that posts it into a channel.
Anything the caller POSTs to that address is carried into the workflow as formData. A supplier confirming with {"orderId": "A-91", "status": "shipped"} gives your later steps {{ 4.formData.orderId }} and {{ 4.formData.status }}.
The address is created when the step runs, not when you build the workflow, and each one answers for a single run. There is no address to copy out of the panel beforehand. Calling an address a second time, after the run has moved on, does nothing.
Run the workflow once and confirm it is waiting before you build on it. Open the step’s Executions tab after the run: a suspended step shows a pending status and its resume address, and the steps after it have not fired. That check takes a moment and tells you the address is live and reachable before you hand it to a supplier or post it into a channel.
On form submitted
The same suspension, but the address opens a page a person fills in. Configure the page with:
| Field | What it does |
|---|---|
| Form Title | Heading shown above the form |
| Form Description | Short explanation shown under the heading |
| Form Fields | The fields somebody fills in. At least one is required |
Each field takes a Field name, which is the key later steps read it by, and a Label, which is what the person sees. You also set a Type, whether it is Required, and optional Placeholder and Help text. The choice types take a comma-separated list of Choices.
The types available are short text, long text, number, date, dropdown, multi-select, checkbox, radio and file.
The form page shows the workflow’s name, your title and description, and the deadline if you set one. Once somebody submits, the page says so. A second visitor to the same link sees that it has already been answered.
The answers arrive as formData, keyed by the field names you chose. A field named reason is read by a later step as {{ 4.formData.reason }}.
Both waiting modes resume through a published workflow. Where the workflow is no longer Live, the address reports that it needs publishing rather than continuing the run.
Resumed and Expired
The two waiting modes give the step two outputs, listed under Branches: Resumed and Expired.
Drag a connection from each to the steps that should follow it. Resumed is the normal path, taken when the call or the submission arrives. Expired is taken when nothing arrives in time.
Leave Branches empty and the step behaves like any single-output step. Resuming continues down its normal output, and expiring settles the run through its error path. An unanswered wait is therefore visible as a failure rather than mistaken for an answer. Wiring the Expired branch turns that into a path of its own, such as a chaser email or a hand-off to a person.
Timeout (seconds) is what sets the deadline. Leave it blank or at 0 and the step waits indefinitely, and only Resumed can ever fire.
What it passes on
What the step publishes depends on its mode.
For a time interval and Until a specific date and time, the step publishes one value:
| Reference | Contains |
|---|---|
{{ N.result }} | A sentence confirming the wait, e.g. “Next steps will be executed after 2 days” |
The two timed modes wait and then carry on, so there is nothing else worth
passing down. If a later step needs the moment the run resumed, use
{{ $now }} there rather than reading it back off this step.
On webhook call and On form submitted, while the run is paused:
{
"status": "pending",
"waitMode": "form",
"resumeUrl": "https://…",
"formUrl": "https://…",
"expiresAt": "2026-08-10T09:00:00.000Z"
}formUrl is the page a person opens, and appears in form mode only. expiresAt is null when there is no timeout.
Once the wait resumes, the step’s own result carries what came back:
| Reference | Contains |
|---|---|
{{ N.formData.<name> }} | What was submitted, or what the caller sent |
{{ N.decision }} | resumed or expired |
{{ N.answeredAt }} | When the answer arrived |
Steps before the Wait are untouched by it. Anything later steps need from them is read as usual.
Limits
A timeout, and a timed wait, both run to a maximum of 13 days. The field refuses a larger number when you type it. To pause for longer, end the workflow and start a second one on a Scheduler trigger at the date you want.
For anything longer, run the later half of the work as its own workflow on a Scheduler Trigger rather than holding a run open. That is also the better shape for “every morning at nine”, which is a schedule rather than a pause inside one run.
Examples to copy
Stay under a third party’s rate limit
Put a Wait of Amount 2, Unit Seconds as the last step of a Repeater loop body, before the connection back into the Repeater step. Each pass then waits before the next begins, so the requests arrive spread out rather than all at once.
Continue on the renewal date
Set Wait Mode to Until a specific date and time and Resume at to {{ 1.renewalDate }}. The run continues on the day named in the record that started it, with no scheduled job to maintain.
Wait for a supplier to confirm
Set Wait Mode to On webhook call and Timeout to 172800 for two days. Follow the Wait with an HTTP Request that sends {{ 4.resumeUrl }} to the supplier as a callback address. Wire Resumed to the fulfilment steps and Expired to a chaser email.
Ask somebody for the missing detail
Set Wait Mode to On form submitted and add a short text field named poNumber. Email {{ 4.formUrl }} to the account manager. Later steps read {{ 4.formData.poNumber }}.
Because Glow is multiplayer, a teammate watching a running workflow sees when a Wait step started and when it is due to resume.
What’s Next?
- Run a workflow on a recurring clock instead of pausing mid-run with the Scheduler Trigger.
- Ask a named person for a decision, with buttons and branches of your own, using Human Review.
- See execution ceilings in System Limits & Quotas.