Scheduled workflow misses most cron slots: 2 of 10 ran, one 27 min late

[MattMcQueen]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Schedule & Cron Jobs

Discussion Details

The schedule trigger in my public repository MattMcQueen/brand-new almost never fires. The workflow is .github/workflows/build.yml ("Build site") on the default branch main. Its state is active, and it runs normally on push, pull_request and workflow_dispatch. GitHub Status showed Actions as operational throughout.

Scheduled slots and what happened (all times UTC)

Date	Cron slot	Result
26 Sep	08:17 (17 8 * * *, on main since 25 Sep 10:06)	Never ran
26 Sep	10:47 (47 10 * * *, added 09:20)	Never ran
26 Sep	12:22, 12:37, 12:52 (temporary test, 7,22,37,52 * * * *, added 12:07)	Never ran
26 Sep	13:07 (test)	Ran at 13:11
26 Sep	13:22 (test; the test schedule was removed at 13:23)	Never ran
26 Sep	14:17 (17 14 * * *)	Ran at 14:44, 27 minutes late
26 Sep	(no slot)	A scheduled run started at 17:46:59. No slot is due then, but it's minute 47, like the 10:47 slot that never ran that morning
27 Sep	08:17	Never ran
27 Sep	10:47	Never ran

So of ten slots, two ran (one of them 27 minutes late), plus one run at a time that matches no slot, unless it was the 10:47 slot seven hours late. The repository only has these three scheduled runs in total.

What I've checked

• Actions is enabled and the workflow is active (not disabled for inactivity: the repository is two days old and has had many pushes).
• The cron expressions are valid, and the workflow is on the default branch at the usual path.
• New commits have been pushed to main after each schedule change, in case the schedule needed to be registered again.

I know the docs say scheduled runs can be delayed or dropped at busy times, but missing eight of ten slots, at quiet minutes like :17 and :47, seems more than that.

Workaround, in case it helps anyone else

The workflow rebuilds a website with fresh data once a day, so I can't rely on the schedule. It's now started from an Azure Logic App (Consumption plan, a Recurrence trigger in UK time) through the workflow_dispatch API:

POST https://api.github.com/repos/OWNER/REPO/actions/workflows/build.yml/dispatches
{"ref": "main", "inputs": {"fetch": "true", "skip_if_fresh": "true"}}

The token is a fine-grained personal access token for that one repository with only Actions: read and write. The workflow's first job stops early if the site already has today's data, so several daily slots are harmless. Those runs start within seconds, every time. I've kept the cron slots as a backup.

Questions

1. Has anyone else seen a schedule that almost never fires on a new repository? Is there a known fix, such as a way to get the schedule registered again?
2. Was the 17:46 run on 26 September most likely the 10:47 slot running seven hours late?

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[2171001]

• Question 1: Yes, this exact scenario occurred on a new repository that missed eight out of ten scheduled slots, despite the workflow being active and the cron expressions being completely valid. Attempting to re-register the schedule by pushing new commits to the default branch did not fix the problem. Since GitHub's documentation states that scheduled runs are essentially best-effort and can be delayed or dropped during heavy load, there is no definitive internal fix when the platform's queue fails to process them. The only reliable workaround demonstrated was circumventing the internal GitHub cron trigger entirely by using an external Azure Logic App to call the workflow_dispatch API.

• Question 2: It is highly likely. While it was not mathematically exact down to the millisecond, an unscheduled run initiated at 17:46:59. Because this execution perfectly matches the 47th minute of the missed 10:47 morning slot, it strongly indicates that the GitHub Actions queue finally processed the dropped job approximately seven hours later.