A schedule runs work on a recurring basis without anyone asking for it. Find them under the factory's Schedules view.
What schedules are good for
Recurring maintenance that is easy to agree on and easy to forget:
- dependency updates
- housekeeping that accumulates — dead code, stale flags, unused exports
- recurring reports
- periodic checks against a standard you have adopted
The common property is that the work is well-defined in advance. A schedule cannot decide what is worth doing; it repeats an instruction you already wrote.
What they are bad for
Anything needing judgement about priority. A schedule that opens work every Monday regardless of what else is happening will compete for the same agent slots as the work you actually planned.
Scheduled work uses real capacity
This is the thing to internalise before creating several schedules.
A scheduled task is an ordinary task. It queues, it consumes an agent slot, and it consumes model spend. Three daily schedules on a one-slot plan can crowd out everything you meant to do.
Run history
Each schedule keeps a history of runs and what they produced. Check it occasionally — the failure mode of automation is not dramatic breakage, it is quietly producing nothing useful for months while consuming budget.
If a schedule has opened twelve pull requests and you merged none of them, the schedule is wrong.
Schedules, Sentinel and hooks
Three ways work starts without a person:
| Mechanism | Triggered by |
|---|---|
| Schedule | Time |
| Sentinel | A condition being observed |
| Hook | A platform event |
Use a schedule when the trigger genuinely is time. If what you actually mean is "when this becomes true", that is Sentinel, and it will do less pointless work.