Skip to main content

Wait

Pauses the flow for a fixed amount of time.

Purpose​

Holds the flow for a set number of milliseconds — to let an animation finish, a screen settle, or a network call return before the next step.

It is a plain timer. It does not look at the screen.

When to use it​

  • Letting an animation or transition complete before reading the screen.
  • Settling the display after a Swipe or Zoom.
  • Deliberately pacing a flow so it does not act at machine speed.

When not to use it​

  • To wait for something to appear. A Find Image or Check Region with a timeout does that properly: it returns the instant the thing shows up instead of always burning the full delay.
  • As a fix for flakiness. A Wait that "usually works" is a race condition with extra steps.
The rule of thumb

Wait for a condition when one exists. Wait for time only when nothing observable marks the end of the thing you are waiting for.

Requirements​

None. Wait runs without a connected device.

How it runs​

  1. Validate the duration (50–120000 ms).
  2. In random mode, pick a uniform integer delay between the min and max for this execution.
  3. Sleep in small cancellable chunks so a Stop takes effect promptly.
  4. If the run is cancelled during the wait, route Cancelled; otherwise route Success and report the actual time waited.

The chunked sleep is why a 60-second Wait does not block you from stopping a run.

Settings​

SettingTypeRangeDefaultWhat it does
Wait modechoicefixed, randomfixedOne fixed delay, or a new random delay each execution
Durationinteger50–120000 ms—Required. The fixed delay, and the fallback if a random pair is incomplete
Duration mininteger50–120000 ms—Random mode lower bound
Duration maxinteger50–120000 ms—Random mode upper bound
Reasonstring≤ 500 chars—A note shown in the run log explaining why this pause exists

Random mode​

With waitMode: random, the runtime picks a fresh uniform integer delay in [min, max] per execution. A Wait inside a loop therefore pauses a different amount every iteration.

This matters for two reasons: it stops a flow from producing a perfectly regular timing signature, and it naturally spreads load when many instances run the same flow.

Duration stays required — it is the fixed value and the fallback if the random pair is ever incomplete.

Use the Reason field​

Reason costs nothing and appears in the run log. "let the map settle after centring" tells you in six months why that 900 ms is there. Undocumented magic numbers are how flows rot.

Ports​

PortTaken whenRequired
SuccessThe full wait elapsed (output: milliseconds actually waited)Yes
CancelledThe run was stopped during the waitNo — never followed
FatalThe duration is outside 50–120000 msNo — never followed

Wait has no Failure and no Timeout port. A wait cannot fail; it can only be cancelled or misconfigured.

Basic example​

Let an opening animation finish:

  • Duration: 1000 ms
  • Reason: "opening animation"

Realistic example — settle after a gesture​

The randomised settle absorbs the variation between a fast machine and a slow one, and the following detection confirms the result rather than assuming it.

Advanced example — pacing a loop​

Inside a loop that repeats an action many times, a fixed delay makes every iteration identical. A random one does not:

  • Wait mode: random
  • Duration min: 1000, max: 1500
  • Reason: "human-like pacing between trips"

Best practices​

  • Replace Waits with detection wherever a condition exists. This is the single biggest speed win available in most flows.
  • Randomise repeated waits. Fixed delays in a loop are both slower and more uniform than they need to be.
  • Always fill in Reason.
  • Prefer one deliberate Wait over several scattered ones. If you find three Waits in a row, the flow is guessing.
  • Never use Wait to "make retry work". Configure backoff on the node's retry policy instead.

Performance notes​

  • A Wait costs exactly its duration, every single time. This is the key difference from a detection node, which returns as soon as its condition is met and only burns the full timeout in the worst case.
  • Replacing a 2000 ms Wait with a Find Image on a 2000 ms timeout typically costs 200–400 ms in practice, because the image is usually there quickly.
  • Waits multiply inside loops. A 1500 ms wait in a 200-iteration loop is five minutes of doing nothing.

Memory notes​

  • Wait allocates nothing and holds no frame. Its footprint is zero.
  • Because it sleeps in cancellable chunks, a long Wait does not hold any resource open.

Common mistakes​

MistakeWhat happensFix
Fixed waits everywhereSlow and still brittle — devices varyWait on a detection result
Too short for the animationThe next node reads a mid-transition frameRaise it, or verify with detection
Using Wait instead of retry backoffRetry has its own backoffConfigure backoffMs on the node
Duration below 50 msFatal — outside the valid rangeMinimum is 50 ms
Expecting a Failure portThere is noneWait cannot fail

Troubleshooting​

The flow is slow but every node looks fine. Add up your Waits. Fixed delays are the usual cause of a flow taking minutes when it could take seconds.

The wait seems to be ignored. Check whether the node is on the executed path at all — an unwired branch never runs.

The node exits Fatal. The duration is outside 50–120000 ms. In random mode check that both bounds are in range.

Stopping the run takes a moment during a long wait. Expected — the sleep is chunked, so cancellation lands at the next chunk boundary rather than instantly.

FAQ​

What is the longest wait? 120000 ms — about two minutes. For longer pauses, use the Scheduler.

Does a random wait re-roll each loop iteration? Yes, once per execution.

Can the duration come from a variable? durationMs accepts a whole-string {{variable}} reference. The random bounds are plain integers.

Does the Wait count toward the run duration guardrail? Yes. All wall-clock time counts toward maxRuntimeDurationMs.