Sleep
Pauses the flow, then continues. Reach for it to let an external system catch up—waiting out a rate limit, giving an asynchronous job time to land—before the next step reads the result.
How long it pauses is set by the Schedule field, which offers two ways of saying it. A new Sleep step starts with neither chosen—the two are different enough that neither is the obvious default—so pick the one that matches how you know the pause.
Sleep For
Pauses for a span counted from the moment the step runs.
| Field | Description |
|---|---|
| Duration | How long to pause, counted in the selected unit. |
| Unit | Milliseconds, Seconds, Minutes, Hours, or Days. |
Sleep Until
Pauses until a given moment. Most useful bound to a variable—an API's retry-after value, a due date, a scheduled publish time—so the moment comes from whatever ran before this step.
| Field | Description |
|---|---|
| Timestamp | The moment to continue at. Accepts an ISO-8601 timestamp, epoch milliseconds, or a plain yyyy-MM-dd HH:mm:ss. |
| Time Zone | Under Advanced. The zone a timestamp carrying no zone of its own is read in. Leave blank for the server's zone. |
If the moment has already passed by the time the step runs, the flow continues immediately and the run log records that it did.
Time zones
A timestamp that carries an offset—2026-09-18T14:30:00Z, 2026-09-18T14:30:00-04:00—already names a moment, as does one given as epoch milliseconds. Time Zone has no effect on either.
It applies to a bare wall-clock reading, such as 2026-09-18 14:30:00 or 2026-09-18, which names a time but not where. Without it, such a value is read in the server's zone, which is rarely the zone the reader had in mind. Set it when an upstream system reports local times and always reports them from the same place.
A zone this server does not recognize fails the step rather than falling back to the server's zone, which would move the resume time by however far apart the two are.
Dynamic values
Both Duration and Timestamp accept a variable in place of a typed value, so the length of a pause can be decided by an earlier step. A variable that resolves to something unusable—a duration that is not a number, a timestamp in no recognized format—fails the step rather than guessing, and names the value it could not use.
Leaving a step unfinished
Nothing about a Sleep step blocks a save—not the missing schedule, and not an empty field inside one—so a step can be left half-configured and returned to later. Once the step has been saved at least once, anything it still needs carries a "Required to run" warning and is counted by the automation's attention badge. Completeness is enforced when the automation runs, not while it is being edited: a step that reaches a run without a schedule fails there.
What later steps see
Nothing of its own. The step passes its incoming payload through unchanged, and later steps go on referencing earlier outputs exactly as they would without it.
Behaviour
While paused, the run holds without consuming resources, then resumes on its own. A pause draws nothing from the automation's execution budget, however long it lasts.
There is still a ceiling: a single run has a limit on its total wall-clock life. A Sleep For duration longer than that ceiling is flagged in the form, because the run would always time out at this step rather than continuing.
Upgrading
Sleep was previously a single Sleep For (ms) field, always counted in milliseconds. Existing steps are converted to Sleep For with the unit set to Milliseconds, preserving the pause exactly. A step that has not been opened since the upgrade keeps running at its original length until it is next saved.