Wait
Step · Stable
Pause execution for a duration, until a timestamp, or until an event fires.
Single-condition wait: set exactly one of duration, until, at_time, or event. duration accepts strings like “2h”, “1d”, “30m”. until accepts an ISO timestamp or a Jinja2 template that resolves to one. at_time accepts a daily wall-clock time “HH:MM” (e.g. 09:00) and resumes at its next occurrence in the workspace timezone — always in the future. event waits for a named platform event with optional timeout. The run enters WAITING state; the scheduler wakes elapsed waits every 60s.
Multi-condition wait (synchronization): add a conditions list with policy: all (wait for every condition) or any (proceed on the first one). This parks the run on a list of conditions — event, signal, or timer — and is about synchronization of WAITING, not parallel compute. A mandatory timeout prevents an all-policy wait from hanging forever. NOT the same as parallel execution (Routario does not support parallel compute).
When to use
Section titled “When to use”Use to introduce a deliberate delay between steps — send a follow-up email 3 days after an initial one, resume at 9am next business day, or hold until a named platform event fires. The run enters WAITING state and resumes automatically; no polling or external scheduler needed.
When not to use
Section titled “When not to use”If you need to pause on MULTIPLE conditions simultaneously (e.g. both a timer AND a signal), use Checkpoint instead — it handles the multi-condition synchronization case. If you need a human to provide input before continuing, use Ask Actor.
Inputs
Section titled “Inputs”duration
Section titled “duration”string · optional
A relative delay from when this step runs. Combines units: d (days), h (hours), m (minutes), s (seconds) — “2h30m” is valid. Set exactly one of duration/until/at_time/event, never more than one.
Example: 3d
- ✓
3d— a 3-day follow-up delay - ✓
2h30m— two and a half hours — combined units - ✗
1 day— not the compact unit syntax — use “1d” (no space, short unit letter)
string · optional
An absolute wake time — either a literal ISO timestamp or a {{ template }} that resolves to one at run time. If the resolved time is already in the past, the step is skipped immediately rather than waiting.
Example: 2026-08-01T09:00:00
- ✓
2026-08-01T09:00:00— a fixed future date and time - ✓
{{ trigger.due_date }}— a per-run deadline carried in from upstream data - ✗
next Monday— not an ISO timestamp — use a real date or a template that resolves to one
at_time
Section titled “at_time”string · optional
A wall-clock HH:MM. Resumes at its NEXT occurrence — if it is already past 09:00 today when the step runs, it resumes tomorrow at 09:00, in the workspace timezone.
Example: 09:00
- ✓
09:00— resume at the next 9am, e.g. a start-of-business follow-up - ✗
9am— not the expected HH:MM format — use “09:00”
string · optional
The platform event name to wait for — same vocabulary as the Event trigger. Pair with timeout below so the run does not wait forever if the event never fires.
Example: invoice_paid
- ✓
invoice_paid— resumes as soon as that invoice event fires - ✗
trigger_event— a step/trigger id, not an event name — use the platform event this step is really waiting for, e.g. ‘invoice_paid’
timeout
Section titled “timeout”string · optional
Only meaningful alongside event (single-condition wait) — how long to wait before giving up. Same unit syntax as duration. On timeout the run FAILS rather than proceeding — no event ever fired.
Example: 24h
- ✓
24h— give up after a day if the event never fires - ✗
0— a zero timeout defeats the purpose of waiting for the event at all — give it a real window
Auto-generated from the skill registry (load_skills()). Do not edit by hand.