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. In the running example, "Every weekday at 7:30" became Every weekday (Monday to Friday) at 07:30 (Asia/Jakarta).
Before you start
- Read Create an Automation to see how users ask for an automation.
The five kinds
| Kind | The user says (Atlas examples) | What is stored |
|---|---|---|
| Once | "Tomorrow at 9, remind me to submit the KG-F12 form", "on 15 October at 14:00" | One date and time. The automation finishes after it runs. |
| Every few minutes or hours | "Every 2 hours, check the status of KG-2052" | An interval in minutes. |
| Every day | "Every day at 7 and 16, list open safety incidents at the Surabaya site" | One or more times of day (up to 24). |
| Every week | "Every weekday at 7:30, check KG-2041", "every Monday at 8, list capex requests waiting for approval" | The days of the week, plus one or more times. |
| Every month | "On the 31st of each month at 16:00, send me a digest of approvals still pending" | A day of the month, plus one or more times. In a shorter month it runs on the month's last day, so "the 31st" works as an end-of-month digest. |
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. Useful for a project that hands over at year end. |
| Maximum runs | "…10 times." The automation finishes after that many runs. |
Time zone
A schedule always carries an explicit time zone, such as 07:30 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 (for Atlas,
Asia/Jakarta); - UTC, as a last resort.
The time zone is always shown in the preview the user confirms, so a wrong guess is corrected before anything is saved. A site supervisor in Makassar who wants 07:30 local time says "7:30 Makassar time", and the preview shows Asia/Makassar. 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. Atlas mentions it in the preview notes: "Runs are at least 15 minutes apart on this agent." |
| 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, for example before an 08:00 site meeting, 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 the KG-2041 check 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.
Check the result
In the automation preview, check three things before confirming:
- The Trigger names the right days and time, for example "Every weekday (Monday to Friday) at 07:30".
- The time zone is the one the user works in.
- The Next runs list the dates the user expects. For the KG-2041 check, they were Mon 5, Tue 6 and Wed 7 Oct 2026.
Next steps
- Next in the journey: Conditions, to run the task only when something is worth reporting.
- Troubleshooting Runs: why a scheduled run was late or skipped.