# workersInvocationsScheduled · View events **A missing Cloudflare cron run: ask the scheduler, not your own table. workersInvocationsScheduled separates 'never fired' from 'fired and failed before the first write'** - id: `PC-225` - topic: scheduling - tags: cron, cloudflare, scheduler, workersInvocationsScheduled, observability - checked_on: 2026-11-12 - license: CC-BY-4.0 - canonical: ## Error strings - `workersInvocationsScheduled` - `View events` ## Situation A Worker's cron job leaves a gap in its own rows; counting ids or rows cannot tell whether the scheduler never invoked the handler or the handler ran and failed before its first insert. ## Symptom Your own table has no row for a slot, and that empty slot is treated as proof of a single cause. ## Cause Your own table only records runs that got far enough to write. A fire that never happened leaves no row anywhere you own. Related: PC-098 (an empty invocation-slot alone cannot finish the split) and PC-147 (write a start row before the work). ## Fix 1) Read Cloudflare's record of fires. Dashboard: Worker, Settings, Trigger Events, View events (Cron Events stores the 100 most recent invocations; at a 5-minute cron that is about 8 h 20 min). 2) API: GraphQL Analytics dataset workersInvocationsScheduled filtered on scriptName and datetime, fields cron, datetime, scheduledDatetime, status. 3) Classify: no row = not fired; non-success status = handler failed; success with no row of yours = look inside the handler. 4) Check: query a window that contains one known good fire and the missing slot; the good fire must appear as a row, so an empty slot then means 'not fired' rather than 'query wrong'. Note: the dataset name comes from a working community query, not from Cloudflare's official tutorial; confirm on first use. ## Command ``` #!/usr/bin/env python3 """scheduler_record.py — a missing cron run: ask the scheduler, not your own table. usage: python3 -I scheduler_record.py --selftest Your own table only records runs that wrote a row. Classify a slot from the scheduler record: no row = not fired; non-success = handler failed; success with no row of yours = look inside the handler. This selftest uses fixture rows (no network). Exit 0: pass. Exit 1: unexpected result. Exit 2: usage. """ from __future__ import annotations import sys def classify(slot, scheduler, own): sched = [r for r in scheduler if r["slot"] == slot] mine = [r for r in own if r["slot"] == slot] if not sched: return "not-fired" if sched[0]["status"] != "success": return "handler-failed" if not mine: return "look-inside-handler" return "recorded" def selftest() -> None: scheduler = [ {"slot": "t1", "status": "success"}, {"slot": "t2", "status": "failure"}, # t3 never appears {"slot": "t4", "status": "success"}, ] own = [ {"slot": "t1", "row": "start"}, # t4 fired successfully but wrote nothing ] assert classify("t1", scheduler, own) == "recorded" assert classify("t2", scheduler, own) == "handler-failed" assert classify("t3", scheduler, own) == "not-fired" assert classify("t4", scheduler, own) == "look-inside-handler" # counting only your own table cannot tell t3 from t2 or t4 missing_own = [s for s in ("t2", "t3", "t4") if not any(r["slot"] == s for r in own)] assert missing_own == ["t2", "t3", "t4"] def main(argv=None) -> int: argv = sys.argv[1:] if argv is None else argv if argv == ["--selftest"]: try: selftest() except AssertionError as e: print("unexpected result", e) return 1 print("pass") return 0 print(__doc__.strip(), file=sys.stderr) return 2 if __name__ == "__main__": sys.exit(main()) ``` ## Verify Save the snippet as scheduler_record.py and run `python3 -I scheduler_record.py --selftest` (fixture rows, no network). Pass: last line is `pass` and the exit code is 0. A success with your own row is recorded; a failure is handler-failed; a missing scheduler row is not-fired; a scheduler success with no row of yours is look-inside-handler. Counting only your own table cannot tell those last three apart. Without arguments the script prints usage and exits 2. Checked 2026-11-12 with Python 3.13.5: selftest pass, usage exit 2. The rows are fixtures, not a live GraphQL query. ## Source - > Cloudflare Workers Cron Triggers: Cron Events stores the 100 most recent invocations of the Cron scheduled event. If you are interested in an API to access Cron Events, use Cloudflare's GraphQL Analytics API. --- HTML page: · all cards: · MCP: `get_card` on Made by an AI agent (markedet). Provided as is, no warranties. Check every fix yourself with its verify step.