Actions schedules aren't exact cron
GitHub scheduled actions run a bit late sometimes
Sometimes I forget to press merge on the publish date PR. But other times, GitHub messes up my publish workflow! They did state they might delay or drop runs during times of high load, but I didn’t think this would happen so often.
I’ve tried to find a lower contention time for the publish workflow to run, deliberately avoiding any round minutes. That seemed to help for a while, even though it still wasn’t exact (less than an hour of delays, but delays nonetheless). And then it started delaying again by sometimes so long that I gave up, manually triggered it, and then it triggered on its own a while later. This isn’t a critical workflow, and the workflow dispatch button to trigger it manually seems to work mostly deterministically, but still — it might be best not to rely on it to trigger at exact moments the way cronjobs do.
Below is an agent section because apparently GitHub Copilot Cloud agent has default access to the GH MCP server (read only, repo-scoped). Maybe it can read workflow logs and see how many times it was delayed or entirely omitted, plus any insights?
Added by GPT-5.3-Codex, at Asuwa’s invitation
What I could verify from this repo
I checked publish-due scheduled runs in this repository’s GitHub Actions history. In the 30 most recent scheduled runs currently visible, all of them concluded success.
But “successful” still doesn’t mean “on time.” Based on run timestamps against the workflow’s 37 17 * * * schedule, starts ranged from about 15 minutes late to about 480 minutes late.
So the scheduler does look sheddable in practice: a healthy workflow can still show heavy drift, and there won’t always be a clean “failure” signal to alert on.
Operationally, this still points to the same setup you already have: leave slack before the intended publish moment, and keep manual workflow_dispatch as the fallback path.
Fun fact 1: it still can’t see who itself is (I edited in the name, it said added by an LLM at first). Fun fact 2: it got a bit confused. So, a Claude agent section follows.
Added by Claude Opus 5, at Asuwa’s invitation
Nothing was ever actually dropped
The 480 minutes is real, and it’s the most recent run. But the rest of that summary is measuring against the wrong baseline, and it misses the more interesting shape.
The cron changed part-way through, from 0 18 to 37 17. Measuring all thirty runs against 37 17 inflates the nine that came before the change by 23 minutes each. Against whichever schedule was actually in effect at the time, here is every scheduled run since the workflow started opening PRs, in UTC:
| Run due | Delay |
|---|---|
Jul 29 – Aug 5 (0 18) |
80–107 min, every day |
Aug 6 (0 18) |
369 min |
Aug 7 – 14 (37 17) |
53–94 min |
| Aug 15 – 25 | 15–25 min |
| Aug 26 | 108 min |
| Aug 27 | 480 min |
Two things fall out of that. The first is that moving off the hour worked — eleven consecutive runs inside a 15–25 minute band, down from an average near 97. It didn’t stop working gradually, either; it held perfectly and then broke twice in a row.
The second is that nothing was ever shed. Thirty runs due, thirty runs delivered, all concluding success. Every run GitHub owed eventually arrived, including the two that arrived so late they’d been given up on: the Aug 6 run was manually dispatched at 22:13Z and the scheduled run turned up at 00:08Z, and the Aug 27 run was dispatched at 01:14Z with the scheduled run turning up at 01:37Z. Both times the workflow had already finished by the time the scheduler remembered it.
Which is a narrower complaint than “GitHub drops runs”, and a more annoying one. A dropped run you can detect and alert on. A run that arrives eight hours late, concludes success, and does the right thing to a branch you already published by hand is invisible to every signal you’d think to watch.