Schedules and triggers: run workflows automatically

A trigger always runs the workflow's published version, never the draft. You can keep editing and testing on the canvas while the schedule keeps running what you last published. Publish the workflow before you add a trigger; until then the trigger form refuses it. See Publishing and versions.

Start workflows that are meant to run on their own with a Schedule trigger node. The trigger's payload reaches the workflow as {{ trigger.<field> }}, exactly like a manual run's test payload.

1. Open Triggers in the sidebar and choose Create a trigger.
2. Give it a Name, such as "Morning digest", and pick the Workflow. The workflow cannot be changed later; make a new trigger instead.
3. Choose how often it should Repeat: every 5, 10, 15 or 30 minutes, hourly, daily, weekly or monthly, at the minute, hour, weekday or day of the month you pick. Or type a Cron expression yourself.
4. Set the Timezone the schedule is read in.
5. Optionally add a Payload, a JSON object passed to the trigger on every run.

Before you save, Next runs shows the next three times the trigger will fire, in your chosen timezone, so a mistake in the schedule is visible straight away.

A cron expression has five fields: minute, hour, day of month, month and day of week (0 is Sunday). Some common ones:

0 9 * * 1-5     every weekday at 09:00
*/15 * * * *    every 15 minutes
0 * * * *       at the start of every hour
30 7 1 * *      07:30 on the first of each month
0 18 * * 5      every Friday at 18:00

• The schedule is read in its own timezone, an IANA name such as Europe/London or Asia/Colombo. A 9am schedule stays at 9am local time across daylight saving changes.
• A trigger may fire at most every 5 minutes, since every run has a real cost.
• A date that never comes around, such as 0 0 30 2 * (30 February), is rejected with a message rather than saved.

The Triggers page lists every trigger with its workflow, schedule, next run and last run. From each row you can:

• Turn it off and on with its switch. Turning a trigger back on schedules the next run from now; it never fires for the time it was off.
• Run now: fire it once straight away with its payload, without changing its schedule.
• Edit its name, schedule, timezone or payload. Renaming it keeps a run that is already due.
• Delete it. The workflow and its run history stay.

Due triggers are checked once a minute. Each trigger is claimed and moved to its next time before its run starts, so it fires once per slot even with several workers, and a scheduler that was down for an hour fires each trigger once when it returns, not sixty times.

If a run cannot start, the trigger's last run shows skipped with the reason: the workflow was unpublished or deleted, its published version no longer validates, or the account reached a usage limit. Runs that do start appear in the workflow's run history with the trigger schedule.