The Worker cron trigger that reported healthy and never ran

I deployed an ingest Worker with a */20 * * * * schedule. Every check I could think of came back green:

• wrangler deploy printed the schedule.
• The Cloudflare API returned the cron under the script’s schedules.
• The deployed bundle contained the scheduled handler.

Then nothing ran. Two consecutive windows passed with wrangler tail completely silent.

How I knew it was the platform, not my code

The job writes last_attempt_at to the database as its very first statement, before it does anything that could fail. If the handler had fired at all, that column would have moved. It did not. That one unconditional write turned a vague “maybe my code is broken” into a clean yes/no signal.

If you operate scheduled work, give every job a first-line heartbeat that cannot fail for business reasons. It is the cheapest observability you will ever add.

What I run instead

The Worker exposes an authenticated fetch endpoint (/run, bearer token). A host crontab line calls it. The job is idempotent, so if the platform trigger ever starts working, a duplicate run is harmless. I left the registered trigger in place because it costs nothing.

7,27,47 * * * *  curl -fsS -H "Authorization: Bearer $TOKEN" https://worker.example/run

The lesson I keep relearning: when a managed scheduler is silent, do not spend a day proving why. Prove that it is silent, move the trigger somewhere you control, and make the work safe to run twice.