Scheduled GitHub Actions workflows never trigger in private repository.

[skeinepu]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Schedule & Cron Jobs

Discussion Details

Hello,

I'm experiencing an issue with scheduled GitHub Actions workflows in my private repository skeinepu/strange-routes.

Affected workflows:

• .github/workflows/refresh-flight-deals.yml
• .github/workflows/scheduler-diagnostic.yml

Both workflows run successfully when manually triggered, but neither receives scheduled runs.

What works:

• Manual workflow_dispatch runs complete successfully.
• The repository's default branch is main.
• Both workflows are enabled.
• Workflow YAML files are present on main.

What doesn't work:

No scheduled runs appear in the Actions history, despite multiple expected trigger times.

The main workflow, .github/workflows/refresh-flight-deals.yml, uses:

schedule:
  - cron: "7 8,14,18 * * *"
    timezone: "Europe/Riga"

To isolate the issue, I created a separate minimal workflow, .github/workflows/scheduler-diagnostic.yml, using:

schedule:
  - cron: "*/10 * * * *"

The diagnostic succeeds when manually triggered, but no scheduled executions appeared during approximately 35 minutes of observation on November 5, 2026.

Could you please investigate whether scheduled workflow triggers are being registered and dispatched correctly for this repository?

The absence of scheduled runs affects both workflows, while manual executions work normally.

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

[naveenjangid2015]

I am experiencing almost the same issue with a scheduled workflow in my private repository.

My findings:

• The affected workflow is Indonesia Website Continuous Monitor.
• Workflow ID: 367605866.
• The workflow file is present on the default branch (main).
• Workflow state is active.
• Manual workflow_dispatch execution completes successfully.
• The monitor job itself completes with success.
• However, no scheduled runs are being created.

Additional troubleshooting performed:

• Restored the workflow schedule to a previously working configuration through PR #61.
• Disabled and re-enabled the workflow using the GitHub API.
• Verified that the workflow remained active afterward.
• Triggered another successful manual run (Run ID: 42043431876).
• Queried the Actions API for scheduled events after reactivation; it returned total_count: 0.

The previous successful scheduled run was on November 5, 2026, at approximately 07:00 AM IST.

This appears to be a similar issue where manual workflow execution works, but scheduled events are not being generated or dispatched.

Could GitHub investigate whether there is a scheduler registration or scheduled-event dispatch issue affecting private repositories?

Thank you.

[nikoladimitrov98]

Your setup looks correct. This matches a scheduler problem on GitHub's side that many people have reported since around Oct 31. In #212128, 5- and 15-minute crons only fired every 4–6 hours, and runs from both workflows arrived together. More reports are linked there (#212101, #211723, #211816, #211839, #211937). GitHub had Actions incidents on Nov 4 described as "an issue with events that might trigger Actions". They're marked resolved, but scheduled runs are still very sparse.

Two things to know:

• 35 minutes is too short a window right now. If runs only arrive every few hours, a */10 cron can look completely dead. Check the run history over a full day before deciding it never runs.
• schedule is best-effort by design, and nothing in your YAML will make it fire on time.

If the flight-deals refresh has to run on time, trigger it from outside GitHub. You already have workflow_dispatch, so any external cron service can call:

curl -X POST \
  -H "Authorization: Bearer <TOKEN>" \
  -H "Accept: application/vnd.github+json" \
  https://api.github.com/repos/skeinepu/strange-routes/actions/workflows/refresh-flight-deals.yml/dispatches \
  -d '{"ref":"main"}'

Use a fine-grained token limited to this repo, with Actions: Read and write permission. Keep the schedule: block as a backup. Once GitHub's scheduler recovers, you can remove the external trigger.

[MatheusWylliam]

Adding a data point that helps narrow this down: your scheduler-diagnostic.yml uses a plain "*/10 * * * *" cron with no timezone key, and it also never fires. That rules out the timezone field in refresh-flight-deals.yml as the cause. Combined with naveenjangid2015's report above (a different repo whose schedule was working until Nov 5 and stopped without any config change), this points to a platform-side dispatch problem rather than a workflow configuration issue.

A quick way to confirm it's not on your side: list scheduled events via the API and compare with expected times:

gh api "repos/skeinepu/strange-routes/actions/runs?event=schedule&per_page=5"

If total_count is 0 over a full day while the diagnostic cron is active on main, there's nothing to fix in the YAML. Until it recovers, an external cron calling the workflow_dispatch endpoint is the reliable workaround.

[skeinepu]

Additional diagnostic result I also checked the repository's GitHub Actions run history using the event:schedule filter. Result: 0 scheduled workflow runs. Both workflows are present on the default main branch, enabled, and execute successfully with workflow_dispatch. However, neither has produced a scheduled run. The independent diagnostic workflow uses */10 * * * * without a timezone setting, so the issue does not appear to be related to the Europe/Riga timezone configuration. This further suggests that scheduled events are not being dispatched for this repository.

…

On Thu, Nov 5, 2026 at 6:13 PM Matheus ***@***.***> wrote: Adding a data point that helps narrow this down: your scheduler-diagnostic.yml uses a plain "*/10 * * * *" cron with no timezone key, and it also never fires. That rules out the timezone field in refresh-flight-deals.yml as the cause. Combined with naveenjangid2015's report above (a different repo whose schedule was working until Nov 5 and stopped without any config change), this points to a platform-side dispatch problem rather than a workflow configuration issue. A quick way to confirm it's not on your side: list scheduled events via the API and compare with expected times: gh api "repos/skeinepu/strange-routes/actions/runs?event=schedule&per_page=5" If total_count is 0 over a full day while the diagnostic cron is active on main, there's nothing to fix in the YAML. Until it recovers, an external cron calling the workflow_dispatch endpoint is the reliable workaround. — Reply to this email directly, view it on GitHub <#212160?email_source=notifications&email_token=BERBVQJMZ6MUEWNHYO3UFB35XSRJTA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOJUGIYTSMZZUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-19421939>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BERBVQLNKCSYZTS777XCDX35XSRJTAVCNFSNUABIKJSXA33TNF2G64TZHMZTAMJVG4ZTGNBUHNCGS43DOVZXG2LPNY5TCMJSGMZDEOJWUF3AE> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/BERBVQLPWZTLTGYYUYWWLUL5XSRJTA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOJUGIYTSMZZUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVJTG633UMVZF62LPOM> and Android <https://github.com/notifications/mobile/android/BERBVQNTRGTVHEUUDI4WZS35XSRJTA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOJUGIYTSMZZUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVZTG633UMVZF6YLOMRZG62LE>. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>

[naveenjangid2015]

Update – November 6, 2026:

I have observed two new successful scheduled runs in my private repository after updating the Indonesia Monitor schedule through PR #62.

Run details:

• 42111354196 – November 5, 21:17:58 UTC – Success
• 42145525718 – November 6, 01:41:40 UTC – Success

However, the expected cron frequency is every 30 minutes (0,30 * * * *). These two runs were approximately 4 hours and 24 minutes apart, and no further scheduled runs have appeared in the latest API results.

Manual workflow_dispatch executions continue to work successfully.

This suggests that scheduled-event delivery may be recovering intermittently, but regular scheduling is not yet confirmed.

I will continue monitoring the workflow and share further results.