GitHub Actions scheduled workflows stopped triggering, but manual runs succeed

[edspectrumfoundation2019]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

ARC (Actions Runner Controller)

Discussion Details

Hello GitHub Community,

I am experiencing an issue with GitHub Actions scheduled workflows in a private repository.

Problem: Three workflows using the schedule event have stopped triggering automatically since 29 October 2026. They were running successfully until 28 October.

What I've confirmed:

• The workflows are enabled and present on the default branch (main).
• Manual workflow_dispatch runs succeed.
• Push-triggered workflows continue working.
• Two existing workflows stopped triggering: an Instagram automation and its Health Monitor.
• Changing and committing their cron expressions did not restore scheduling.
• I created a completely independent diagnostic workflow with cron: '*/5 * * * *', requiring no secrets or external services.
• The diagnostic also did not trigger automatically after more than 30 minutes, although it ran successfully when started manually.

Successful manual diagnostic run:
https://github.com/edspectrumfoundation2019/akshara-reels-automation-Private-GitHub-repository/actions/runs/41029071016

Last successful scheduled publishing run:
https://github.com/edspectrumfoundation2019/akshara-reels-automation-Private-GitHub-repository/actions/runs/40625522951

Last successful scheduled Health Monitor run:
https://github.com/edspectrumfoundation2019/akshara-reels-automation-Private-GitHub-repository/actions/runs/40637600825

These links belong to a private repository, so other community members may not be able to open them.

My question: What could cause all schedule events to stop being delivered for a repository while workflow_dispatch and push events continue working? Is there a way to reset or repair the repository's scheduled event registration without moving to an external scheduler?

Any troubleshooting guidance would be appreciated.

Thank you.

[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. ⭐

[miguelsalva]

Your */5 test basically proves it's not your config. If a workflow with no secrets and no dependencies doesn't fire for 30+ minutes, the problem is on the scheduler side.

As far as I know there's no way to "reset" schedule registration from our side. The one thing I've seen help is disabling the workflow and enabling it again (from the ··· menu in the Actions tab, or gh workflow disable / gh workflow enable). It's quick, so worth a try.

FWIW, schedule is best effort. The docs say runs can be delayed or even dropped under high load, and there are a couple of other threads from the same days with the exact same symptom (#211641, #211632), so I don't think it's just you.

If it's something you really depend on (sounds like it, with the Instagram posts), I'd keep workflow_dispatch and hit it from an external cron via the API. I know you wanted to avoid that, but it's the only thing I'd actually trust for anything time-sensitive.

[christoferpedrosanchezzuzunaga-eng]

Hello @raihan0718,

Scheduled workflows getting dropped is unfortunately a common quirk with GitHub's cron scheduler during peak queue loads. A few checks that usually help identify why:

1. Repo inactivity rule: GitHub automatically disables scheduled workflows on repositories that have had no commit activity for 60 days. If the repo went quiet, a quick commit to main re-enables them.
2. Cron high-traffic minutes: If your cron is set to run at the top of the hour (e.g. 0 * * * * or 0 0 * * *), the global runner pool gets saturated and drops ticks. Changing it to an off-peak minute (like 17 2 * * *) often fixes reliability immediately.
3. Branch check: Make sure the cron workflow file is present on the default branch (main). GitHub only schedules workflows that exist on default.