Scheduling
Run rule sets automatically on a recurring schedule.
A schedule runs a rule set on a recurring cadence without anyone pressing a button. Each schedule lives inside an environment and pairs a rule set with a cron expression that says when it should fire. When the time comes, a run is queued just like one you would start from the runner — the only difference is that the schedule started it, not a person.
Defining a schedule
Open the schedule list for an environment and add an entry. A schedule needs three things:
- A project and a rule set within it to run.
- A cron expression describing the recurrence.
- An Active toggle — inactive schedules are kept but never fire.
As you type the cron expression, the editor shows a plain-language preview of when it will run, so you can confirm the cadence before saving. The list also surfaces the next upcoming run time across your schedules.
0 9 * * * run every day at 09:00 UTC
0 */15 * * * run every 15 minutesShared-host frequency limit
On a Shared or Free tier environment, schedules must leave at least five minutes between runs. The editor rejects cron expressions that would fire more often than that. Dedicated environments run on your own resources and are not subject to this minimum.
How a scheduled run shows up
Every triggered run gets its own correlation id, exactly like an interactive run, so you can trace it in the logs and see that it was started by the schedule rather than a person.