Skip to main content

Schedules

Some flows run on the clock instead of waiting to be called: a morning digest, a nightly data sweep, a weekly summary. A schedule attaches a cadence to a published flow: Workbench runs it for you and delivers the result.

Schedules run the published version of a flow. Draft edits never leak into a scheduled run — publish is the act that changes what the clock executes.

Setting one up

From a flow's detail view, open View → Scheduled runs… and create one:

Cadencehourly | daily | weekly

Daily and weekly schedules anchor to a wall-clock time in a timezone you pick (weekly adds a day of the week). Hourly runs on the hour.

Inputsaved input

The exact input envelope the flow runs with, every time — the same shapes the test panel uses. Change it by editing the schedule; the next run picks it up.

Deliveryhistory | notification | email

Where results land. History records the run quietly (read it in Devtools like any other run). Notification rings the in-app bell with the output. Email sends the flow's output to you — the digest pattern.

Every scheduled run appears in the flow's run history either way, labeled as scheduled and filterable to its schedule — cost, trace, and output, same as any run.

Pausing and failure

Schedules have a pause switch — disabled schedules keep their configuration and pick the next slot back up when re-enabled. A failed or timed-out run always reaches you, whichever delivery you chose: if you asked for email you get an email, and if you asked to keep results in the run history you still get a notification for the failure.

You don't have to wait for the next slot to try one — Run now on a schedule runs it immediately.

What schedules are not

Schedules run flows on your cadence with fixed input. If the input should vary per call — or the trigger is an event, not a clock — call the flow from your own scheduler or service via the public API, or wire it to Slack where the trigger is a message.

2 min read