Skip to main content

Sleep

Use the Sleep step to pause a flow for a configured amount of time before the next step runs. It is the right tool whenever a downstream system needs time to react, or when you want to throttle outbound calls.

Typical use cases include:

  • Throttling outbound calls. Insert a short Sleep between HTTP Request steps so you stay below an external API’s rate limit.
  • Letting an external system catch up. Send a request, Sleep, then poll a follow-up step that reads the result once the external system has had time to process.

Configure the step​

Open the flow editor, add Sleep, and fill in the configuration card.

Description​

  • Purpose: Make it clear why this pause exists in the flow.
  • When to fill it: Always. The description is shown in the editor and execution history.
  • Tips: State both the intent and a hint at the magnitude, for example Wait 30 s for ERP to commit or Throttle DHL calls.

Duration​

  • Purpose: How long the flow should pause.
  • When to fill it: Required. Use a positive integer, or a SmartField token to read the value from a previous step (for example, {{retryDelay}}).
  • Tips: SmartField tokens are resolved when the step runs, so the same step can wait different amounts on different executions.

Unit​

  • Purpose: The unit applied to the duration value.
  • When to fill it: Required. Choose Milliseconds, Seconds (default), Minutes, or Hours.
  • Tips: Pick the smallest unit that fits — small Milliseconds waits stay in process and are cheap; Minute and Hour waits free the worker (see Behavior below).

Behavior​

Sleep produces no outputs. What it does internally depends on the duration and unit:

  • In process — When the unit is Milliseconds and the duration is below 10 000 ms, the worker is blocked for that span and the next step runs immediately afterwards. There is no Job Queue overhead.
  • Deferred — Any other case (Seconds, Minutes, Hours, or ≥10 000 ms in Milliseconds) commits the in-flight execution and schedules a new single-run Job Queue Entry pinned to the resume time. The current run ends; when the Job Queue fires the entry, the engine re-invokes the same Sleep step, which finishes immediately and lets the flow continue.

Each deferred Sleep that is currently waiting consumes one Job Queue Entry, so flows with many simultaneous deferred Sleeps consume that many parallel Job Queue Entries.

Limitations​

  • Job Queue path only. Sleep relies on the Job Queue to wake the execution back up. It must only be used in flows that run from a Job Queue Entry — that is, the standard async path. Do not use Sleep inside a SubFlow or in the synchronous phase of a Webhook trigger — the engine cannot defer there. Validator enforcement of this restriction is tracked separately under CHN-119 (SubFlows) and CHN-123 (Webhooks).
  • Earliest-not-exact wake-up. The configured time is the earliest start time of the resume Job Queue Entry. The actual wake-up depends on Job Queue throughput and may be later if the queue is busy.

Best practices​

  • Match the unit to the wait. Use Milliseconds only when you genuinely need a sub-second pause — they block the worker. Use Seconds, Minutes, or Hours for anything longer so the worker is freed during the wait.
  • Keep loops explicit. When you need a polling pattern (call → Sleep → call again), drive the loop with a Decision step rather than chaining Sleeps. The intent stays visible in the flow graph.
  • Don’t Sleep just to wait for a SubFlow. SubFlows run inline; the parent flow already blocks while they execute. Add Sleep only between steps in the main flow, where deferral is meaningful.