Scheduled and recurring work
A job can run on a schedule rather than waiting to be asked. Schedules belong to a job, carry a timezone, and are held to the unattended approval rules, so work that fires overnight is treated more carefully than work you asked for in person.
Last updated 2026-09-04.
What a schedule is
A schedule is a standing instruction attached to a job: run this, this often, in this timezone. It is not a separate automation, which is why it inherits the job description, the connected apps and the approval rules you already set.
The timezone is stored with the schedule rather than taken from whoever created it. A daily report meant for a nine in the morning read stays at nine when the person who set it up is travelling.
Setting one up
- 1
Write the standing request
Say what you want done and what done looks like, in the same words you would use asking a person. "Every Monday, tell me which accounts went quiet last week and which one is worth a call" is a good one.
- 2
Pick the cadence and the timezone
Daily, weekly, monthly or a specific date. Set the timezone to the one the output is read in, not the one you happen to be in when you set it up.
- 3
Check the unattended rules
A scheduled run is unattended by definition, so it uses the stricter rule. If the job should send something at four in the morning, that has to be allowed explicitly.
- 4
Say where the result goes
A channel, a thread, or the console. A scheduled job that produces something nobody sees is the most common way this goes wrong.
When a run fails
A failed run is recorded with what it was trying to do and where it stopped. It does not silently retry forever, and it does not quietly stop existing, which are the two failure modes that make people distrust automation.