Skip to content

Wait

Pause the run for a fixed duration, or until a signal arrives.

A waiting run holds no agent, so it can wait for minutes or for weeks at no cost, and it survives restarts and deploys while it waits.

  • Kind: wait
  • Palette: Flow
  • Run it on its own: no, only as part of a graph
  • A delay: “wait a day, then send the follow-up”.
  • A pause until something outside the run says go: another system sends a named signal with spool run signal <run> <name>, and its payload becomes this node’s output.

To wait for a person, use an approval, which gives them a form. To wait for an event on the project bus, use an event node.

Field Type Required Description
duration string no How long to sleep, e.g. “30s”, “5m” (set exactly one of duration/signal).
outputs object no Rename what comes out: {output_name: key_in_the_raw_output}. Absent passes the raw output through.
signal string no Signal to wait for; its payload becomes the node output.
timeout string no How long to wait before giving up, e.g. “1h”; the output then says timed_out.

The signal payload, when one was awaited, plus:

Field Type Description
timed_out boolean True when the deadline won rather than the thing being waited for.
version: hyperspool-graph/v1
nodes:
- id: welcome
type: shell
config: { run: ./send-welcome.sh }
- id: later
type: wait
config: { duration: 7d }
- id: follow_up
type: shell
config: { run: ./send-follow-up.sh }
- id: go
type: wait
config:
signal: go-live
timeout: 48h
- id: launch
type: shell
if: "!nodes.go.output.timed_out"
config:
run: { $template: "./launch.sh {{ nodes.go.output.env }}" }
edges:
- { from: welcome, to: later }
- { from: later, to: follow_up }
- { from: follow_up, to: go }
- { from: go, to: launch }

go waits up to two days for spool run signal <run> go-live --payload '{"env":"prod"}'. A deadline that passes doesn’t fail the step: its output says timed_out: true, and the if: on launch decides what that means.

See the node reference for every other node.