Live measurement

How late are GitHub’s scheduled workflows?

We run the same tiny workflow two ways in a public repository: on GitHub’s own schedule: trigger, and triggered by Cronkick. Both are timed the same way, from GitHub’s own run list.

The same workflow, run two ways

Every 5 minutes, once on GitHub’s own schedule: and once triggered by Cronkick, in Deveshb15/cronkick-probe-a. 46 h measured.

GitHub schedule:Cronkick
Ran when it was due1.3%7 of 556100%556 of 556
Typical delay4 min 2 shalf started later1.0 shalf started later
Worst 5%4 min 58 s1 run in 20 or later3.0 s1 run in 20 or later

Latest 96 due times · the same instants on both rows, hover one

Cronkick

GitHub schedule:

within 30 slaternever ran

How late each run started · log scale, hover a dot

Cronkick

GitHub schedule:

How it’s measured

The same clock
For both, lateness is the time from the scheduled minute until GitHub created the run, read from the repository’s run list on GitHub.
The same minutes
Both sides are counted from when both workflows were running (an hour after a new GitHub schedule, ten minutes after a new Cronkick twin) to the last complete check, less an hour.
Only real runs
A Cronkick run counts only if the Cronkick app started it; clicking “Run workflow” never counts. A scheduled minute with no run an hour later counts as never ran.
Honest gaps
A failed or partial check is never counted as a miss. If GitHub turns a schedule off after 60 days without commits, that pair pauses instead.

Sample

Each check reads at most 1,000 runs per repository; if the collector were down for more than about 3 days, that repository would stay at its last complete check (“incomplete: hit the 1,000-run cap”).

ScheduleTriggered byHours measuredDueRanNever ranTypical delay (p50)Worst 5% (p95)
*/5 * * * *GitHub schedule:46 h556798.7%4.0 min5.0 min
*/5 * * * *Cronkick46 h5565560.0%1 s3 s
0 * * * *GitHub schedule:46 h46687.0%4.8 min49.9 min
0 * * * *Cronkick46 h46460.0%2 s4 s