Cron vs Event Triggers for AI Agent Work

The short answer

Pick cron when the work may wait for the next polling interval and you need a clear bound on execution frequency. Pick an event-driven trigger when the agent should start as soon as the source reports a change, provided the path can handle duplicate deliveries and bursts. For important work, use both: events as the fast path and a reconciliation cron as the repair path.

The central trade-off is timing versus delivery behavior. Cron bounds how often execution starts, but its detection-delay bound equals the polling interval. Event-driven work reacts immediately rather than waiting for a poll, but it inherits duplicate delivery and burst behavior from the event source.

Criterion	Cron schedule	Event-driven trigger	Events plus reconciliation cron
Execution frequency	Bounded by the schedule	Follows the source’s event rate, including bursts	Event rate on the fast path, plus a bounded repair schedule
Detection delay	Can equal the polling interval	Reacts immediately when the event arrives	Immediate normally; missed work waits for reconciliation
Duplicate and burst behavior	The schedule does not inherit event bursts	Inherits duplicates and bursts from the source	Fast path still needs duplicate and burst handling
Missed or malformed events	Does not depend on an event arriving	Can leave work undiscovered	Reconciliation scans for and repairs the gap

Cron: bounded execution with bounded delay

A cron path runs a scheduled handler that looks for eligible work. Cloudflare’s Cron Triggers documentation, last updated June 20, 2026, describes cron expressions mapped to a Worker’s scheduled() handler and gives intervals from every minute to monthly schedules. The same mechanism applies whether the handler starts work directly or finds records for an agent to process.

The benefit is a frequency bound you can state before deployment. A schedule of */15 * * * * produces four scheduled starts per hour. That makes cron a good fit when the requirement is “check no more than every 15 minutes,” not “start immediately after every change.” For the broader mechanics of recurring execution, see scheduling delayed and recurring agent work.

The cost is detection delay. If the source changes just after a 15-minute poll, the change may remain unseen until the next one. The detection-delay bound is therefore the polling interval: one minute for a one-minute schedule, 15 minutes for a 15-minute schedule, and one hour for an hourly schedule. Shortening the interval reduces that delay by scheduling more checks; lengthening it reduces scheduled executions by accepting a longer wait.

Cron is the wrong primary trigger when the work must begin before the next polling interval. Making the interval extremely short does not turn polling into event delivery; it only schedules checks more often. Cron fits when waiting for the interval is acceptable and when bounding execution frequency matters more than reacting at source-change time.

Events: immediate reaction with source-shaped load

An event-driven path starts when the source reports that something happened. It does not wait for the next scheduled scan, so it reacts immediately to the source notification. Here, “immediately” means without polling delay; it does not claim that the agent’s work itself has zero runtime.

That speed transfers control over arrival shape to the source. If the source sends the same event more than once, the consumer may see it more than once. If many events arrive together, the consumer receives a burst rather than the evenly bounded starts supplied by cron.

This is not an edge condition that can be ignored. Cloudflare’s queue delivery guarantees, last updated April 21, 2026, state that its queues use at-least-once delivery by default and can rarely deliver a message more than once. The documentation recommends a unique ID as a primary key or idempotency key when duplicate processing would cause unintended behavior. The standing for event-driven work is therefore clear: it wins on reaction time but requires duplicate-safe processing whenever the source can redeliver.

Bursts require the same explicit treatment. GitHub’s webhook best-practices documentation, checked August 26, 2026, advises subscribing only to needed events, returning a successful response within 10 seconds, and moving payload processing to an asynchronous queue when necessary. It also tells receivers to check the event type and action before processing, redeliver missed deliveries, and use the delivery identifier to distinguish events.

For an agent path, that means acknowledging ingress separately from doing the multi-step work, filtering events before starting the agent, and carrying a stable delivery or work identifier into processing. The queue can absorb arrivals, but it does not remove duplicate delivery; the consumer still needs an idempotent boundary. Reliable webhook ingress for agent systems covers that boundary in more detail.

Event-driven triggering is the wrong answer by itself when duplicate execution would be harmful and no deduplication rule exists, or when a burst can start more agent work than the path can accept. The trigger is immediate, but the event source—not your preferred schedule—determines how deliveries arrive.

The hybrid: events for speed, cron for repair

An event-driven fast path and a reconciliation cron solve different failure cases. The event starts normal work immediately. The cron periodically asks which source records should have been processed and compares that set with completed or accepted work. If an event never arrived, or arrived with a type, action, or payload the ingress path could not process, reconciliation can submit the missing work through the same duplicate-safe boundary.

That repair schedule does not make the event path exactly once. Duplicate delivery and bursts still exist, and both the event consumer and reconciler can identify the same work. They therefore need the same stable work key so that finding a gap twice does not create two agent runs.

The reconciliation interval becomes the repair bound. With a 15-minute reconciliation cron, normal events can start immediately, while a missed or malformed event may wait for the next 15-minute scan. This preserves the event path’s reaction time without pretending every event will be delivered once in valid form.

The cost is an additional path to operate: immediate ingress plus a scheduled comparison. That cost is justified when silently missing agent work is worse than detecting it later. It is unnecessary when the job is already periodic, the polling delay is acceptable, and there is no event-driven fast path to repair.

Which to pick when

Pick cron alone when the work is naturally periodic, a delay as long as the polling interval is acceptable, and bounding scheduled execution frequency is the deciding condition.

Pick event-driven triggers alone when immediate reaction is required and the event source’s duplicate delivery and burst behavior are already handled by filtering, queuing, and a duplicate-safe work key.

Pick events plus a reconciliation cron when immediate reaction matters but missing work is unacceptable. Let events start the usual case, then use cron to repair missed or malformed events. Keep the repair interval no longer than the maximum delay you can accept for discovering a gap.

The default for important source-change work should be the hybrid: event-driven for prompt execution, reconciliation cron for recovery. The default for genuinely periodic work should remain cron; adding events cannot improve a requirement that is defined by the clock.