Run a Worker’s scheduled() handler on recurring UTC Cron triggers. Definitions
live in your Wrangler project; the tenant console provides delivery visibility
and operational pause/resume controls.
Configure recurring work
Add triggers to wrangler.jsonc and deploy with wrangler deploy:
{
"triggers": { "crons": ["*/5 * * * *"] }
}Export a scheduled(controller, env, ctx) handler from the Worker. It receives
the Cron expression and planned time and can use the Worker’s ordinary bindings.
Wrangler replaces the complete trigger set after publishing code. Removing an
expression removes that trigger; setting an empty list removes them all.
Inspect and control delivery
Open Compute → Schedules in your organization. Filter by Worker name, Cron expression, or state. Select a Worker name to see each expression, its next delivery, last successful scheduled time, and last delivery outcome. Cron expressions use UTC; displayed timestamps use your browser’s timezone.
Owners, administrators, and members can pause or resume that Worker’s schedules. Observers can inspect them but cannot change delivery state. Pausing prevents new deliveries while allowing in-flight work to finish. The override persists across service restarts and Wrangler deployments; deploying code does not silently resume paused work. Organization suspension separately stops deliveries for the entire organization and does not erase individual Worker pauses.
Follow Scheduled invocations or Execution logs to the Worker’s filtered observability view when investigating a result. A successful delivery means the invocation completed successfully, not that an external business transaction was independently verified. Pause and resume emit platform lifecycle events.
Delivery and recovery
The scheduler provides at-least-once delivery. Native Durable Object alarms, SQLite state, and durable leases coordinate delivery on the Worker’s assigned data shard. Failed deliveries are retried, and a restart can result in a duplicate invocation. Make externally visible side effects idempotent.
After downtime or a pause, the coordinator may deliver one overdue occurrence before advancing to the next future occurrence. It does not replay every missed interval as a backlog. This is not a hard real-time scheduler: runtime load, delivery retries, and shard updates can delay execution. State is not replicated or automatically failed over to another host.
Scheduled invocations contribute to the organization’s Worker invocation meter alongside HTTP, service-binding, and queue activity. See Usage and quotas and Observability for interpretation of usage and execution telemetry.