cronscan

Overview ¶

Command cronscan asks whether an organisation's SCHEDULED workflows actually fire, by counting the firings their cron expressions ask for against the `schedule` runs GitHub recorded.

cronscan go-pkgx --days 14

WHY IT EXISTS ¶

A scheduled job that never runs fails in the quietest way there is: nothing is red, nothing is logged, and a capability nobody invokes is a capability the fleet does not have. Every other scanner here reads what DID happen — prscan and redscan read runs and requests, wfaudit reads a workflow's security — and none of them can see an absence.

⛔ THE LISTING LIES BY TRUNCATION. On 2026-10-19 I believed go-pkgx's schedules were half broken: `gh run list --limit 6` on its versioncheck showed six runs, all `push` or `pull_request`, with no `schedule` among them. It was a busy afternoon of pushes and the scheduled runs were simply further down. cronscan said 14 of 14. Counting needs the whole list and a denominator; a glance gives neither.

⛔ AND THE DENOMINATOR MUST RESPECT THE WORKFLOW'S AGE. Asking "how many firings does a daily cron want in 14 days" answers 14 for a file that has existed for one. The first version of this printed `want 14 got 0` for three jobs merged the previous evening, beside `want 14 got 14` for the established ones — which reads as an organisation whose schedules are half dead. The window's floor is whichever is later, the span asked for or the workflow's own created_at.

⛔ AND ITS CEILING MUST RESPECT THE DELAY. A firing due two hours ago has not been missed on a service measured to run five and eight hours late; it is pending. Run at 07:18 UTC on 2026-10-20 without this, the pass reported `3 of 52 firing(s) did not happen` — three one-day-old daily jobs whose morning run had simply not arrived — and a scanner that is red every morning on a healthy fleet is a scanner nobody reads. So the window ends at now minus --grace (default 9h, from the 8h worst case measured here), and runs recorded inside the grace window still count: this errs toward believing the fleet, because the alternative errs toward crying wolf daily.

WHAT IT FOUND, AND THE FACT WORTH KNOWING ¶

Over 14 days go-pkgx asked for 49 firings and got 49. The schedules are reliable — but they arrive HOURS LATE: a job with `37 5 * * *` fired at 11:13 UTC, and a Monday `0 5 * * 1` at 12:56 UTC. So "my cron should have run by now" is wrong before about 14:00 UTC, and somebody checking the Actions tab in the morning concludes the job is dead. Measure at the end of the day, or over days.

A commented-out cron is not counted: `# - cron: "0 6 * * *"` is how this fleet disables one, and counting it would report a workflow as failing to run a schedule nobody asked for.