---
title: "Schedules"
---

> Documentation Index
> Fetch the complete documentation index at: https://ermahgerd-docs.t-bd7662a5eeb4.workers.ermahgerd.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Schedules

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`:

```json
{
  "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](/quotas/)
and [Observability](/observability/) for interpretation of usage and execution
telemetry.

Source: https://ermahgerd-docs.t-bd7662a5eeb4.workers.ermahgerd.io/schedules/index.mdx