What is an AI worker schedule?
A worker schedule is a standing instruction that runs an AI worker on a cadence in your own time zone, without anyone asking it to.
A schedule is the smallest thing separating an assistant from a worker. Everything else can be identical; if nobody has to start it, it is a worker.
Schedule or trigger?
The two ways a worker starts, and the test is latency, not importance:
| Schedule | Webhook trigger | |
|---|---|---|
| Starts on | A clock | An event in another system |
| Good for | Digests, sweeps, reports, reviews | Reactions that must be fast |
| Latency | Up to one interval | Seconds |
| Cost when nothing happened | A run's worth of tool calls | Nothing, it never fired |
| Notices it was never called | Yes, it ran anyway | No |
| Real kit | Engineering Pulse, a morning GitHub digest | Inbound Lead Qualifier, fires when a lead lands |
Most serious workers want both: the trigger for speed, the schedule as the safety net that catches whatever the trigger missed.
Wall clock, not UTC drift
Schedules run in your own time zone, and that is a contract rather than a convenience. A worker set for 8am runs at 8am after the clocks change, not at 7 or 9.
Systems that store schedules in UTC and convert on read get this wrong twice a year, in a way nobody notices until a daily report starts landing an hour late in March.
What the plans allow
| Plan | Schedules per worker |
|---|---|
| Free | 1, hourly or daily |
| Pro | Unlimited, to the minute |
| Team | Unlimited, to the minute |
| Enterprise | Unlimited |
Two things worth pulling out. Free is genuinely useful rather than a demo: one daily schedule is exactly what a first job needs. And **one-time "run once at" schedules are not capped on any plan**, including Free, so scheduling a single future run is never rationed.
Choosing a cadence
The instinct is to run things often. Resist it: every run costs tool calls and model tokens, and most jobs have a slower natural rhythm than they feel like they do.
| Cadence | Fits | Real kit |
|---|---|---|
| Weekly | Reports, hygiene passes, audits | Weekly Ops Reporter, SEO Watchtower |
| Daily | Digests, morning briefs, overnight triage | Executive Daily Briefing |
| Hourly | Queues needing attention within the working day | Support Inbox Triager |
| To the minute | Alignment, not frequency: land output before a 9:00 standup | Pro and Team only |
Frequency is the multiplier on everything. A worker doing 8 tool calls once a day is 8 a day; the same worker every minute is 4,800. If a job must react within seconds of something happening, it does not want a schedule at all.
Unattended is not unwatched
Every scheduled run leaves a receipt showing what it read, what it did, what it cost and what it skipped. Log history is 1 day on Free, 30 days on Pro, 365 on Team.
A worker you cannot inspect is one you will eventually switch off. The receipt is what makes a schedule something you can leave running.
When a schedule is the wrong trigger
A clock is the default and it is not always the right one. Four cases where something else fits better:
| The job | Why a schedule fits badly | Use instead |
|---|---|---|
| React to an event within seconds | Any interval is too slow, and polling spends its budget finding nothing | A webhook trigger |
| Answer a question when someone asks | There is nothing to check on a cadence | On demand, like Company Knowledge Concierge |
| Do one thing at one future time | A standing cadence is the wrong shape | A one-time "run once at" schedule, uncapped on every plan |
| Poll faster than the cap allows | Every 15 minutes is 576 tool calls a day against Free's 500 | A trigger, or accept slower |
The last row is where the decision usually gets forced. Wanting lower latency leads people to shorten the interval until it stops fitting the plan, at which point the honest options are to find the event or to accept that the job runs hourly.
There is also a case where nothing helps: if you cannot say what a run should do, the cadence is not the problem. Fix the instruction first, because a schedule only decides how often an unclear job runs unclearly.
FAQ
Do WorkerKit schedules follow my time zone or UTC?
Your own time zone, on wall-clock time. A worker set for 8am runs at 8am through daylight saving changes, rather than drifting by an hour twice a year.
How many schedules can one worker have?
Free allows one schedule per worker, hourly or daily. Pro and Team allow unlimited schedules to the minute. One-time "run once at" schedules are not capped on any plan, including Free.
Should I use a schedule or a webhook trigger?
Use a schedule when the job has a natural rhythm and "within the hour" is fine. Use a webhook trigger when the job is a reaction that must happen within seconds. A minute-by-minute schedule is usually a trigger nobody has wired yet: it burns tool calls all day finding nothing and still reacts up to a minute late.
What happens to a schedule if my worker loses an app permission?
The worker keeps running with whatever access is left, and the receipt records what it could not do. Permissions can be narrowed or switched off at any time without stopping the worker, which is the point of the app firewall.
Do scheduled runs cost more than on-demand runs?
No. A run costs the same however it started: its tool calls against your plan's daily allowance, plus model tokens at provider list price with no markup. Frequency is what changes the total, which is why cadence is worth choosing deliberately.