Unify Logo Footer.svg
Unify Automations
Logo
Listen for signals

Listen for signals

Logo

4 mins READ

The Wait for Signal node pauses an automation until a matched signal arrives, then resumes with the signal's payload. Use the long wait (persisted) variant for pauses that must survive service restarts or long gaps between emit and wait.

Overview

The wait side of a Signals pair suspends the current automation and holds it until the expected signal arrives. Three wait variants serve different needs: a standard Wait for Signal suited for short, in-session pauses; a Long Wait that writes the wait state to durable storage so it survives service restarts and extended gaps; and Wait for Multiple Signals that holds until all specified signals have arrived. Every wait has a configurable timeout — if the signal does not arrive in time, the automation resumes anyway with a timeout flag set and an empty payload. Always design the step after a wait to check for this flag.

Wait for Signal node configuration

Operations

Wait for Signal

Pauses the automation until a signal with the matching automation, node, and signal ID arrives. On resume, the emitter's payload is available as data pills in subsequent steps. Configure a timeout; if the signal does not arrive within the timeout window, the automation resumes with a timeout flag and an empty payload.

Long Wait (Persisted)

Writes the wait state to durable storage before suspending. The wait survives service restarts and can remain active for extended periods. Use this variant whenever the gap between the emitter and the wait node may be long, or when the wait must remain active across a deployment. Pair it with the cleanup option on the corresponding Emit Signal node so the saved signal state is freed after delivery.

Wait for Multiple Signals

Holds the automation until all specified signals have arrived. Each named signal can carry its own payload. A partial set of signals does not resume the automation early — all must arrive within the timeout window. On timeout, the automation resumes with a timeout flag regardless of which signals did or did not arrive.

Timeout and Payload Behaviour

Every wait variant has a configurable timeout (a duration and unit). On timeout:

  • The automation resumes automatically — it does not block indefinitely.

  • The resume context includes a timeout flag set to true and an empty payload.

  • The step immediately after the wait should read the timeout flag and branch accordingly — do not assume the payload contains signal data.

The payload schema you attach to an emit is described for the builder's convenience but is not strictly enforced at runtime. Design downstream steps to tolerate missing or unexpected fields rather than assuming the payload is perfectly shaped.

Emit-before-wait risk: For standard (non-persisted) waits, a signal emitted before the wait node is reached can be missed. Use the Long Wait variant for resilient hand-offs where the emit and wait order cannot be guaranteed.

Notes

Keep the following in mind when configuring signal waits.

  • Every wait has a timeout. On timeout the automation resumes with a timeout flag and empty payload — always check the flag in the next step.

  • Signal matching is by automation ID, waiting node ID, and signal ID. The emitter and waiter must agree on the same signal ID.

  • For ordinary waits, if the signal is emitted before the wait node is reached, the signal can be missed. Use the Long Wait to avoid this.

  • The Long Wait requires the emitter to set the cleanup option so saved signal state is freed after delivery.

  • Wait for Multiple Signals blocks until all specified signals arrive — a partial set does not trigger early resume.

  • The payload schema is not strictly enforced at runtime; design downstream steps to tolerate variation.

Always test signal flows end-to-end, including the timeout path, to confirm that the "signal never arrived" case is handled gracefully before deploying to production.

FAQs

What is the timeout flag and where do I check it?

When a wait times out, the resume context includes a flag indicating the signal never arrived. Read this flag in the step immediately after the wait node and branch your logic accordingly — never assume the payload contains signal data after a timeout.

When should I use Long Wait instead of the standard wait?

Use Long Wait whenever the gap between emit and wait may be long, when the automation must survive a service restart while waiting, or when you cannot guarantee the emitter fires before the waiter is paused. Standard waits are appropriate for short, in-session hand-offs where timing is controlled.

Can Wait for Multiple Signals resume early if most signals arrive?

No. Wait for Multiple Signals holds until all specified signals have arrived. It does not resume on a partial set. On timeout it resumes regardless of which signals did or did not arrive, with the timeout flag set.