Your GitHub cron is 20 minutes late, or six hours

My android-rom-compat repo pulls in new device data every Monday at 17 6 * * 1. I chose minute 17 since everyone knows not to use :00, becuase top of the hour is when GitHub’s busiest (according to their workflow schedule docs).

Here’s when it actually ran:

$ gh run list --event schedule \
    -R NotAFlightRisk/android-rom-compat \
    --json createdAt --jq '.[].createdAt'
2026-10-12T15:33:46Z
2026-10-05T14:47:28Z
2026-09-28T14:02:11Z
2026-09-21T12:54:11Z

Do you see the issue? Yeah, against the 06:17 it asked for, it was six and a half hours late, then seven and three quarters, eight and a half, and over nine. Actually, seems it gets later every week.

Another of my repos has the same cron, and on the 12th it started at 15:33:46 too, to the second. Both were stuck in the same queue, and the queue was nine hours long.

So this got me curious, and I went and checked a few hundred other people’s results…

Two lanes

Scheduled runs on public repos are all visible through the Actions API. So I took a random mix of active repos, from tiny to very popular, and measured every daily cron in them over the first two weeks of October. Here’s how late each one typically ran:

• Under 1 h298
• 1-2 h0
• 2-3 h6
• 3-4 h51
• 4-5 h51
• 5-6 h65
• 6-7 h162
• 7 h or more26

Nearly half run within the hour, usually about 20 minutes late. The rest are almost three hours late or worse, usually six. Interestingly, between one and two hours there’s nobody at all, so it’s basically two lanes with nothing in the middle.

It’s not a bad day here and there, either. A workflow that’s six hours late on Monday is six hours late on Tuesday, and on Wednesday. They almost never swap lanes.

Who gets the slow lane

Anything under a few thousand stars is more likely to be slow than not. Only the really big repos get prioritized

• Under 1094%
• 10-9968%
• 100-99961%
• 1k-3k63%
• 3k-10k36%
• 10k+3%

Personal repos mostly get it worse than org ones. I doubt stars are what GitHub actually looks at. More likely it’s how busy the repo is, or something else that comes with being popular, and you can’t see that from outside, so tbh I dont know. It’s not down to the plan you’re on though - nextcloud has a 17-star repo in the slow lane and a 10k-star one in the fast lane, under the same org.

And schedules on :00 were no more likely to be slow than the rest.

It started on 27 August

0 h2 h4 h6 h8 h10 h12 h

Slow nowFast now

13 Aug26 Aug8 Sep21 Sep4 Oct14 Oct

The numbers

day	Slow now	Fast now
13 Aug	1.7 h	0.5 h
14 Aug	1.6 h	0.5 h
15 Aug	0.7 h	0.2 h
16 Aug	0.7 h	0.2 h
17 Aug	0.8 h	0.2 h
18 Aug	0.8 h	0.3 h
19 Aug	0.8 h	0.3 h
20 Aug	0.8 h	0.3 h
21 Aug	0.8 h	0.3 h
22 Aug	0.7 h	0.2 h
23 Aug	0.8 h	0.2 h
24 Aug	0.9 h	0.3 h
25 Aug	0.8 h	0.2 h
26 Aug	0.9 h	0.3 h
27 Aug	10.2 h	2 h
28 Aug	11.5 h	3 h
29 Aug	6.3 h	0.2 h
30 Aug	5.1 h	0.2 h
31 Aug	6 h	0.3 h
1 Sep	4.8 h	0.3 h
2 Sep	4.3 h	0.3 h
3 Sep	4.3 h	0.3 h
4 Sep	4.3 h	0.2 h
5 Sep	3.8 h	0.2 h
6 Sep	4 h	0.2 h
7 Sep	4.8 h	0.3 h
8 Sep	4.4 h	0.2 h
9 Sep	4.5 h	0.2 h
10 Sep	4.4 h	0.2 h
11 Sep	4.4 h	0.2 h
12 Sep	4 h	0.2 h
13 Sep	4.7 h	0.2 h
14 Sep	5.3 h	0.3 h
15 Sep	4.8 h	0.2 h
16 Sep	4.6 h	0.2 h
17 Sep	4.7 h	0.2 h
18 Sep	4.4 h	0.2 h
19 Sep	4.1 h	0.2 h
20 Sep	4.5 h	0.2 h
21 Sep	5.3 h	0.3 h
22 Sep	4.7 h	0.2 h
23 Sep	4.6 h	0.2 h
24 Sep	4.8 h	0.3 h
25 Sep	4.8 h	0.2 h
26 Sep	4.6 h	0.2 h
27 Sep	5.1 h	0.3 h
28 Sep	6.2 h	0.3 h
29 Sep	5.7 h	0.3 h
30 Sep	5.7 h	0.3 h
1 Oct	6.1 h	0.3 h
2 Oct	5.7 h	0.3 h
3 Oct	5 h	0.3 h
4 Oct	5.6 h	1.3 h
5 Oct	6.8 h	0.4 h
6 Oct	6.3 h	0.3 h
7 Oct	6.1 h	0.3 h
8 Oct	6.4 h	0.3 h
9 Oct	6.2 h	0.3 h
10 Oct	5.8 h	0.3 h
11 Oct	6 h	0.3 h
12 Oct	7 h	0.5 h
13 Oct	6.7 h	0.4 h
14 Oct	4.9 h	0.2 h

Before the 27th, the repos that are slow now were often behind, but they were spread out, with no gap between them and the rest.

On 26 August GitHub had an Actions incident. The database behind the service that triggers workflows got overloaded, and the write-up says this:

Several changes to improve the general scalability of this part of Actions were already complete and deploying to production. Rollout of those changes will be complete within the next 24 hours.

27 and 28 August were a mess for everyone, with nothing about it on the status page. Then from the 29th, one group went back to about 15 minutes late. The other hasnt had a day under three and a half hours since, and it’s getting worse - about four and a half hours in early September, six by October.

I can’t tell you if the rollout caused it. The timing matches, and that’s all I’ve got. Someone else noticed schedules going missing on those same dates, and five weeks on the only reply is from GitHub’s bot. It’s not totally new either - back in July this thread had a brand new repo running 8-14 hours late almost every day.

What to do about it

Run the gh run list above on your own repo and compare it with your cron. Under an hour late, you’re fine. Hours late every day and you’re in the slow lane, and moving the minute won’t get you out of it.

If the time actually matters, stop asking schedule: for it. Add workflow_dispatch: to the workflow and kick it off from something that keeps time, like a cron on a box you already run:

gh workflow run import.yml -R you/your-repo

In the August thread, dispatched runs started in the same minute 209 times out of 209.

My own Monday import is still on 17 6 * * 1, mind. It’s device data, and nobody’s waiting on it at quarter past six on a Monday.