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 Schedules 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 pane 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 the dev drawer 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. If a scheduled run fails or times out, the failure is delivered through the same channel you chose (a failed digest emails you the failure).

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.

GuideShip to production

Publishing, pinning, and the version discipline schedules rely on.

GuideInspect runs

Reading the run history your schedules write into.

2 min read