Hourly schedule produces runs only every 3–8 hours; manual runs succeed

[chemice9]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Schedule & Cron Jobs

Discussion Details

An hourly scheduled workflow in my private repository on GitHub Free runs roughly every 3–8 hours, while manual runs succeed.

Schedule on default branch main:

on:
  schedule:
    - cron: '10 * * * *'
  workflow_dispatch:

By our September 30, 2026 inspection, 11 scheduled runs had succeeded since September 28. Examples on September 30 (UTC): 08:22, 15:51, and 20:44. The last completed in 55 seconds. We expected approximately hourly execution allowing normal delays, but see multi-hour gaps without corresponding errors in run history.

Checks performed:

• Actions and the workflow are enabled; main is the default branch.
• Disabling and re-enabling did not promptly resolve the issue.
• The initial September 27 allowance check showed only 2/2,000 included minutes used.
• A minimal five-minute diagnostic that only printed the time and event type produced no runs during approximately 15 minutes, then was disabled. This short test alone is not conclusive.
• The job condition explicitly permits github.event_name == 'schedule'. Concurrency uses cancel-in-progress: false. Completed jobs typically take roughly a minute.

I understand that scheduled runs may be delayed or dropped and exact timing is not guaranteed. Are repeated 3–8-hour gaps expected? Is there a known scheduler issue or account/repository restriction to investigate? What diagnostics or configuration changes would distinguish those causes? Would changing plans actually improve scheduling, or is an external scheduler needed for dependable hourly triggering?

I searched for similar reports and found https://github.com/orgs/community/discussions/208916. These are additional hourly/private-repository observations; I do not know whether the underlying cause is the same.

Private repository links and application data are omitted. I can provide run references privately through an appropriate support channel if needed.

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

[Sagargupta16]

Expected right now, not something about your repository or plan.

Measured on a public repository on a personal Free account (so not private, not minutes-limited): two hourly crons, 17 * * * * and 47 * * * *. Since 2026-09-26 the first has fired 22 times in about 115 hourly slots; since 2026-09-28 the second 13 times in 74. Gaps run 2 h 35 min to 8 h 33 min, median about 5 hours, and not a single run started on its scheduled minute. Your 11 runs since 2026-09-28 is the same ratio. #208916, which you found, is a public repository with daily crons showing the same thing over four days, so neither visibility nor the hourly cadence is the variable.

The documented behaviour covers it, barely: "The schedule event can be delayed during periods of high loads ... some queued jobs may be dropped." Your off-the-hour minute already follows the docs' advice; it is not helping anyone this week.

Diagnostics that separate causes:

gh run list -R OWNER/REPO --event schedule --limit 100 --json createdAt,conclusion --jq '.[].createdAt'

Steady runs on random minutes with multi-hour gaps = platform queueing (what you have). No runs at all for 60+ days = the schedule was disabled for inactivity. Runs that start but fail = your workflow.

A plan change buys nothing here; the scheduler is shared. What does work, exactly to the second in #208916 for four days, is triggering from outside:

curl -X POST -H "Authorization: Bearer $TOKEN" \
  -H "Accept: application/vnd.github+json" \
  https://api.github.com/repos/OWNER/REPO/actions/workflows/FILE.yml/dispatches \
  -d '{"ref":"main"}'

Any cron you trust can call it (cron-job.org, a Cloudflare Worker cron trigger, EventBridge Scheduler), with a fine-grained token scoped to the repo with Actions read/write. Keep the schedule trigger as a fallback and add concurrency so a late platform run and your external run do not overlap.

[kurupdevs]

Your pattern matches a platform-side scheduling backlog, not a config issue. Runs firing at scattered minutes with whole hours skipped means queued runs are being delayed or dropped under load, which GitHub documents as possible for the schedule event. Your setup already follows the documented guidance, with the cron off the top of the hour and the workflow file on the default branch, which is the only branch GitHub reads schedules from. One extra check is to line up your gap windows with the GitHub status page, since identical gaps across unrelated repositories in the same week point to a platform issue rather than anything in your repo. For dependable hourly timing, an external trigger calling workflow_dispatch on a timer is the reliable workaround, and changing plans would not change this scheduling behaviour.