Reliable by Design · 05.15
Triggers, Cron & the Listener Runtime
Manual, cron (natural-language to UTC), webhook, and persistent-listener triggers — how a run actually starts.
Four ways a run starts, one entry point
| Trigger | Mechanism |
|---|---|
manual | UI-side dispatch through POST /v1/workflows/:id/run — not handled by the trigger runtime at all. |
cron | A node-cron schedule, rehydrated automatically from every active trigger at boot. |
webhook | The webhook router looks up the configured trigger, secret, and idempotency window, verifying signatures with HMAC and a timing-safe comparison. |
persistent_listener | The adapter's own createPersistentListener is invoked once per active trigger, and the returned handle is tracked for clean shutdown. |
Whichever path fires, every one of them funnels through the same single fire() entrypoint, which creates the WorkflowRun row and hands it to the engine — so observability (the ledger, realtime events) is uniform no matter which trigger actually caused a run to start.
The listener runtime coordinates the long-lived ones
A persistent listener isn't a fire-and-forget subscription — ListenerRuntime is the coordinator that keeps each active persistent_listener trigger's connection alive, matches inbound events back to the right trigger, and tears connections down cleanly when a trigger is disabled. This is what backs a trigger that has to stay connected to an external stream rather than just waking up periodically.
Continue
Resolves a single capability URN onto one execution path, so chat, workflow, and MCP all delegate through the same trusted handlers.
Restarting a run from a node, a failed branch, an edited node, or a checkpoint — deterministic partial replay.