Overview

cronlag tells you, slot by slot, whether your scheduled GitHub Actions workflows ran when their cron: said — how late, which slots never ran, and whether the cause is your setup or GitHub's scheduler. Then it runs the missed slots without double runs.

Why

Since late August 2026 many repos see scheduled runs created hours late or not at all (community #206019, #206134, #210037). Every thread rebuilds the same table by hand: list the schedule runs, work out which cron slot each belongs to, compute the lag, count the gaps, then walk a checklist of causes. The Actions tab shows none of this — and the REST API doesn't even say which slot a run was for.

How it measures

1. Reads every workflow file on the default branch and its commit history, so each period is judged by the cron that was live then (cron changes mid-window are not "missed" slots). Slots before GitHub first registered the workflow are not counted either, so a workflow added two days ago is judged on two days.
2. Expands the cron with GitHub's rules: * , - /, month and day names, day-of-month/day-of-week OR rule, IANA timezone: with DST gaps moved to the next valid time.
3. Lists runs with event=schedule and ties each to the closest preceding unclaimed slot within 24 hours.
4. Lag = slot → run creation. That happens before any runner is involved, so it is the scheduler. Queue time (creation → start) is reported separately: that one is your runners.

npx github:Blackman99/cronlag owner/repo

Next: Install · Usage