A schedule runs work on a recurring basis without anyone asking for it. Find them in the factory under Automations, and create them in New Work as an automation that runs on a schedule: every few hours, or every day, week or month.
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 and event automations
Two of the ways work starts without a person:
| Automation | Triggered by |
|---|---|
| Schedule | Time |
| Event automation | Something happening, such as a pull request opening or a check failing |
- ScheduleTime
- Event automationSomething happens
An ordinary task
Specification, plan, build, verify, review. Uses an agent slot; give it a lower priority.
P2P3A pull request
It cannot merge itself or commit to your base branch.
You approve
Use a schedule when the trigger genuinely is time, or when what you watch lives in a system that sends Coroid no events, such as Sentry or Jira: the schedule asks it through your MCP servers. If what you actually mean is "when this happens" and Coroid or GitHub sends that event, use an event automation. It will do less pointless work.
Work also starts from your own systems and agents, from event automations and from quality findings. See Ways to start work.