Run a workflow on a schedule#
A schedule trigger starts a workflow every so many minutes or at a time of day, on the days you choose. It runs as the workflow's owner, with an event that says which time it fired for. This page adds one, checks when it fires next, and explains what happens to times that pass while it cannot fire.
Before you begin#
- A workflow (see Build and run a workflow), and the editor role.
- Its inputs all have defaults, or are not required: a schedule gives the event only.
Add the schedule#
- On the workflow's page press Edit (new version).
- From the palette's Start group, drag Schedule onto the graph (or click it).
- In its panel, When: At a time of day (At, On — the days; none ticked is every day — and Time zone, which starts as your browser's) or Every so many minutes (Every (minutes), 5 to 1 440). The Recipe menu has Every 15 minutes, Every day at 8:00 and Mondays at 8:00.
- Press Write the version, with Runs (and its triggers) use this version from now on ticked.
When it fires#
- Every so many minutes fires at the multiples of the interval counted from midnight UTC: every 15 minutes is :00, :15, :30 and :45; every 60, on the hour. An interval that does not divide a day (every 7 minutes) does not land at the same times each day.
- At a time of day fires at that time in its time zone, on its days. A time that does not exist on a day because the clock moved forward is skipped that day; one that happens twice fires the first time.
- From when it is saved. A schedule written or changed fires first at its next time to come — never at a time that already passed today.
- Only the current version's schedules fire.
What the execution gets#
Its event is:
scheduled_at is the time it fired for, in UTC. A box reads it as
${{ event.scheduled_at }}; a run box can turn it into a date (the day
before) in its own code — see A nightly digest.
The execution's page shows Trigger morning (schedule).
It runs as the workflow's owner: whoever created the workflow (its
first version), not whoever wrote the current one. An assistant asked by a model box reads the
owner's memory; a notify box with no to tells the owner.
See when it fires next#
On the workflow's page, Triggers shows each schedule's Next time, when it last fired and the execution it started, and why it last could not start one.
TRIGGER KIND NEXT LAST EXECUTION ERROR, one row per trigger; an HTTP
trigger's NEXT is on a call.
Missed times#
When a time passes and the schedule cannot fire — Astralyx could not start it then — it fires once for that time, up to an hour late. Later than that, it skips it and records Missed as its error; it fires again at its next time. It never fires once for each time missed.
Each time's execution is named after the workflow, the trigger and the time, so a time is never started twice.
When it cannot start#
The schedule records why on its trigger (Triggers, the ERROR column),
and tries again at its next time:
| Error | Why |
|---|---|
inputs.<name>: required |
An input is required and has no default. Give it a default. |
| flow … runs N executions already, its limit: this one was dropped | Every place is taken and the workflow's concurrency drops what comes then. With when_full: queue, it would wait its turn instead. |
Related#
- Triggers
- A nightly digest with an approval
- Workflow specification
- Astraeus schedules — runs on a cron schedule, without a workflow