Schedules
The schedule is the when of an automation — its Time Trigger. Users describe it in ordinary words and the agent turns it into one of five kinds.
The five kinds
| Kind | The user says | What is stored |
|---|---|---|
| Once | "Tomorrow at 9", "on 15 October at 14:00" | One date and time. The automation finishes after it runs. |
| Every few minutes or hours | "Every 2 hours", "every 30 minutes" | An interval in minutes. |
| Every day | "Every day at 8", "every day at 8 and 17" | One or more times of day (up to 24). |
| Every week | "Every Monday at 7", "weekdays at 8:30" | The days of the week, plus one or more times. |
| Every month | "On the 1st of each month at 9" | A day of the month, plus one or more times. In a shorter month it runs on the month's last day. |
Any repeating schedule can also have:
| Extra | Example |
|---|---|
| End date | "…until the end of December." The automation finishes after its last run before that date. |
| Maximum runs | "…10 times." The automation finishes after that many runs. |
Time zone
A schedule always carries an explicit time zone, such as 08:00 Asia/Jakarta. The agent chooses it, in this order:
- one the user names ("8 AM Singapore time");
- the time zone of the user's device or browser;
- the agent's own default time zone;
- UTC, as a last resort.
The time zone is always shown in the summary the user confirms, so a wrong guess is corrected before anything is saved. Repeating schedules keep their local time across daylight-saving changes.
Limits on a schedule
| Rule | Detail |
|---|---|
| Once | Must be at least 1 minute ahead and no more than 1 year ahead. |
| Minimum interval | Consecutive runs must be at least your policy's Minimum Interval apart (default 15 minutes). The agent checks this when the automation is created or edited, and again at every run. |
| Runs per day | The projected runs per day of all of one user's active automations must fit within Maximum Runs per User per Day. |
| Runs per automation | The policy's Maximum Runs per Automation ends an automation when reached. |
If a request breaks one of these, the agent says which and suggests a change — for example a longer interval — instead of creating something that would be stopped later.
What "on time" means
Runs may start up to a minute or so after the scheduled time, and later when many automations are due at once — see How Automation Works. If you need a result by a certain hour, schedule it a few minutes earlier.
If a run is missed
Sometimes a run cannot happen at its scheduled time — for example when the service was unavailable. Each automation has a missed-run policy that says what to do:
| Setting | Meaning |
|---|---|
| Run once, as soon as possible (default, recommended) | If several runs were missed, run once now — the latest matters most. |
| Run as soon as possible | Run now. |
| Skip the missed run | Do nothing until the next scheduled time. |
| Run every missed run | Catch up on each one, up to 10. |
A run that has waited a long time in the queue is skipped only when the automation uses Skip. A missed-run policy can be changed when a user edits the automation on their Automations page.
Editing a schedule
Users can change a schedule in conversation ("change SLA Monitor to 7 in the morning") or on the Automations page. The change cancels the run that was scheduled and schedules a new one, so an old run can never fire after the edit.