FAQ

Why are my scheduled runs late?

GitHub documents that scheduled workflows can be delayed under load and dropped, especially at the start of the hour. Since late August 2026 the delays have been far larger than usual for many repos, including ones on quiet minutes. cronlag can't make GitHub's scheduler faster; it shows you exactly how late it is, rules out causes on your side, and gives you a catch-up path.

How exact is the lag?

The API doesn't say which cron slot a run belongs to. cronlag ties each run to the closest preceding unclaimed slot. For daily or few-times-a-day schedules that is exact in practice. For schedules more frequent than the delay (say hourly with 3-hour lag) a run may be tied to a later slot than it really served, so the lag is a lower bound and the missed count an upper bound. mode: guard reports the precise lag of the run it is in.

Will catch-up cause double runs?

Catch-up only dispatches a slot that has no run after the grace period, and never the same slot twice. If GitHub's delayed run arrives later anyway, add the guard job and it will skip. Without the guard, make the job idempotent (most refresh jobs already are) or use a concurrency group.

Does moving off minute 0 help?

Sometimes. GitHub recommends it, and cronlag suggests a quieter minute. But the 2026 threads show off-peak schedules (:15, :23, :38, :47) failing too, so measure before and after with cronlag --days 14.

Private repos? GitHub Enterprise?

Private repos work with a token that has Actions: read. GHES: point the library's GitHub client at your API base (apiBase); a CLI flag is on the roadmap.

Is anything sent anywhere?

No. The CLI, Action and MCP server talk only to the GitHub API. The landing page's live check runs in your browser against the public API.