Scheduled GitHub Actions workflows never start, but manual runs succeed

[Roy1980]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Schedule & Cron Jobs

Discussion Details

Hello,

I’m investigating why three daily scheduled workflows in a private repository never start, while manual runs succeed.

All three workflows are active and present on the default branch, main. Each includes workflow_dispatch and schedule:

• Database backup: 17 3 * * *
• Repository backup: 47 3 * * *
• Backup freshness check: 17 9 * * *

All times are UTC.

The schedules were added on October 11, 2026. Manual runs completed successfully that day, including their jobs.

On October 13 at 08:38 UTC, the GitHub API reported zero schedule runs since October 11. There were no failed, skipped or queued scheduled runs. The database and repository runs expected that morning had not been created.

Checks completed:

• Repository Actions permissions allow all actions and reusable workflows.
• All three workflows are active.
• The repository variable BACKUP_ENABLED is set to true.
• Current monthly Actions usage is 180 Linux minutes, with $0 billed.
• The Actions budget is $0 with “Stop usage” enabled, but usage is below the included allowance.
• A change to off-hour cron minutes was merged on October 12, but the next scheduled backup runs still did not appear.
• Subsequent merges did not remove or change the schedules.

What else could prevent schedule events from creating workflow runs? Is there a way to verify whether GitHub has registered the schedules, or to request an investigation without changing the cron expressions again?

I can share sanitized workflow excerpts if needed, but cannot share credentials or backup contents.

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

[FelixFangX]

A few things to check beyond what you've already covered:

1. Re-register the schedule. Schedules are registered when GitHub processes a push to the default branch that changes the workflow file, and that registration occasionally fails silently. A common fix that leaves your cron expressions unchanged is to disable and re-enable each workflow:

   gh workflow disable "Database backup" && gh workflow enable "Database backup"

2. Check who last edited the schedule. Scheduled runs are attributed to the user who last modified the cron line. If that commit came from a bot or app identity, or from an account without write access, runs may not be created. Having a maintainer make the latest edit to the schedule can help.

3. Check the workflow file on main. Make sure on.schedule is a list (- cron: '17 3 * * *') with no tab characters, that no workflow-level condition or concurrency setting cancels scheduled runs, and that main is actually the default branch.

4. Check organization settings. A $0 budget with "Stop usage" enabled should not block runs while you're within the included minutes, but it's worth confirming the organization's Actions policy and spending limits as well as the repository's.

To confirm whether any scheduled runs were created:

gh api "repos/OWNER/REPO/actions/runs?event=schedule&per_page=5" \
  --jq '.workflow_runs[] | [.name, .created_at, .status] | @tsv'

There is no public API that lists registered schedules. If the steps above don't help, open a ticket at https://support.github.com with the workflow file paths and the commit SHAs that added the schedules, so they can check the scheduler directly.