cloudflare-workers-cron-emaillisted

This skill should be used when the user asks to debug a Cloudflare Workers Cron Trigger that "isn't firing" or "not running" (or fires on the wrong day), set up or troubleshoot the send_email binding or Email Routing destination addresses for Workers, size a Worker against Cloudflare's per-invocation subrequest limits, test a scheduled() handler locally against real R2/KV/email bindings, verify an R2 delete/rename actually took effect, or rename/reorganize keys in an R2 bucket. Trigger phrases include "cron trigger not firing", "scheduled worker not running", "cron ran on the wrong day", "wrangler cron", "cron trigger debug", "send_email binding", "Workers email binding", "Email Routing destination address", "workers subrequest limit", "test-scheduled --remote", "r2 object rename", "r2 delete not working", "r2 move objects".
jackson2w/claude-code-skills · ★ 1 · AI & Automation · score 67

Install: claude install-skill jackson2w/claude-code-skills

# Cloudflare Workers: Cron Triggers + Email Bindings Diagnose scheduled Cloudflare Workers that silently fail to run, size a Worker's R2/KV workload against subrequest limits before it's built, and wire up the `send_email` binding correctly the first time. This knowledge comes from a real debugging session where a correctly-configured cron trigger and a correctly-coded Worker both looked broken for reasons that took real investigation to isolate. ## Core principle: distrust `wrangler tail` for "did it run?" `wrangler tail` can attach to a stale or reused session and replay old log lines instead of showing genuinely new activity — it produced byte-identical output (down to the same historical timestamp) across two separate invocations during testing, several minutes apart, while a cron trigger was firing on a 2-minute schedule. Treat `wrangler tail` as useful for *watching* a Worker interactively, never as the ground truth for "has this invocation happened." For ground truth, use two Cloudflare APIs instead: 1. **Is the schedule registered?** `GET /accounts/{account_id}/workers/scripts/{script_name}/schedules` Returns the cron pattern and `created_on`/`modified_on` timestamps. See `scripts/check-schedule-registered.sh`. 2. **Has it actually invoked?** The GraphQL Analytics API's `workersInvocationsAdaptive` dataset, filtered by `scriptName` and a datetime range, returns real invocation counts (`sum.requests`, `sum.errors`) per time bucket — independent