Workflow: scheduled background work with Cron Triggers and Queues

# Workflow: scheduled background work

## 1. Cron Triggers for schedules

Declare crons in the Wrangler file. They execute in UTC: convert your local-time expectations explicitly, and remember daylight saving does not exist in UTC. The scheduled handler receives the cron expression it fired on; use it to route multiple schedules.

## 2. Keep the handler light

A cron handler that does heavy work inline risks the CPU limit (1102) and blocks the schedule. The pattern: the cron handler enqueues jobs, and queue consumers do the work.

## 3. Queues for the work

Producers send messages; consumers process with automatic retries. Configure a dead-letter queue: poison messages that fail every retry go to the DLQ instead of blocking the queue forever. Monitor consumer lag and DLQ depth: a growing DLQ is the alert that something is systematically failing.

## 4. Idempotency

Cron can fire a handler more than once in edge cases, and queue retries redeliver. Make consumers idempotent: keyed writes, dedupe on message id. "At least once" is the delivery contract; exactly-once is your code's job.

## 5. Observability

Log from the scheduled handler (which cron fired, how many jobs enqueued) and from consumers (processed, failed, DLQed). Tail during the first few production fires.

## Checklist

- Crons in UTC, handler enqueues, queues do the work.
- DLQ configured and monitored from day one.
- Consumers idempotent; retries are normal, not exceptional.