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.
A schedule decides when a rule set runs. A single rule can separately carry an active date window that decides when that rule is live within any run, scheduled or not. Use a schedule for cadence and rule dates for a policy that starts or ends on a known day.
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.