A schedule runs work on a recurring basis without requiring manual input. You’ll find them under the factory’s Schedules view.
What schedules are useful for
Recurring maintenance that’s easy to agree on and simple to overlook:
- dependency updates
- housekeeping tasks that accumulate — dead code, stale flags, unused exports
- recurring reports
- periodic checks against a standard you’ve adopted
The common trait is that the work is clearly defined beforehand. A schedule cannot determine what’s worth doing; it simply repeats instructions you’ve already written.
When they’re not suitable
Any task needing a judgement about priority. A schedule that starts work every Monday regardless of current demands will compete for the same agent slots as the work you’ve actually planned.
Scheduled work uses real capacity
This is the key point to bear in mind before setting up multiple schedules.
A scheduled task is just an ordinary task. It queues up, occupies an agent slot, and uses model resources. Three daily schedules on a one-slot plan can block everything else you intended to do.
Run history
Each schedule keeps a record of its runs and the results produced. Check it periodically — the typical failure mode of automation isn’t a major breakdown but quietly generating nothing useful for months while still using budget.
If a schedule has created twelve pull requests but none were merged, the schedule is misconfigured.
Schedules, Sentinel and hooks
Three ways work starts automatically without human intervention:
| Mechanism | Triggered by |
|---|---|
| Schedule | Time |
| Sentinel | A condition being monitored |
| Hook | A platform event |
Use a schedule when the trigger is genuinely time-based. If what you need is "when this condition becomes true", that’s Sentinel, which will perform less unnecessary work.