Scheduled GitHub Actions workflow repeatedly skips hourly runs despite successful executions

[alanjanc1995]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Schedule & Cron Jobs

Discussion Details

Hello GitHub Community,

I'm experiencing recurring missing scheduled executions in a private repository using GitHub Actions for hourly hydrological data collection.

Environment

• Repository visibility: Private

• Plan: GitHub Free

• Default branch: main

• Schedule: 17 * * * * (UTC)

• Runner: GitHub-hosted

Observed behavior

The workflow is configured to run hourly, but the recorded scheduled executions are substantially below the expected frequency:

Date (2026) | Recorded runs | Expected runs -- | -- | -- October 22 | 5 | 24 October 23 | 5 | 24 October 24 | 7 | 24

On October 25, successful runs started at approximately 03:11, 08:30, 13:20 and 16:37 Argentina time (UTC−3).

Some gaps exceeded five hours.

What I've verified

• GitHub Actions is enabled.

• The workflow successfully executes when triggered.

• Recent completed runs show no collection errors.

• Concurrency is configured with cancel-in-progress: false.

• No evidence of concurrency blocking was found.

• Account usage is 195 / 2,000 included Actions minutes.

• No apparent billing or storage restrictions.

• The schedule is configured away from the beginning of the hour.

The workflow generally completes within approximately two minutes.

Questions

1. Is this frequency of missing scheduled runs within GitHub Actions' expected scheduling behavior?

2. Were there any known incidents affecting scheduled events on October 22–25, 2026?

3. Is there a way to investigate scheduled events that never produce a workflow run?

4. Would resynchronizing the workflow schedule help, or is there another recommended mitigation for private repositories?

I understand that scheduled workflows can be delayed or occasionally dropped under high load. However, the recurring gaps seem substantial.

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

[iamsomraj]

Unfortunately this is expected behaviour for the schedule trigger. It's best-effort, not guaranteed. From the docs:

The schedule event can be delayed during periods of high loads of GitHub Actions workflow runs. High load times include the start of every hour. If the load is sufficiently high enough, some queued jobs may be dropped.

You've already moved off the top of the hour (17 * * * *), which is the only knob GitHub gives you. For data collection where every hour matters, two things help:

1. Trigger it from outside GitHub. Add workflow_dispatch to the workflow and have an external scheduler (a cloud scheduler, cron-job.org, a small VPS cron, etc.) call the API every hour with a fine-grained token that has Actions: write on that repo:

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

workflow_dispatch runs start reliably, unlike schedule.

2. Make each run catch up. Instead of collecting "the current hour", have the job collect everything since the last successful timestamp, stored in the repo, an artifact or a variable. Then a delayed or dropped run doesn't leave a gap in the data.

If you also want to rule out anything on your side, or raise it with GitHub Support, these two commands give you the facts to work from:

# workflow state should be "active"
gh api repos/OWNER/REPO/actions/workflows --jq '.workflows[] | [.path, .state] | @tsv'

# exact UTC start times of the scheduled runs, so the missing hours are easy to list
gh run list --repo OWNER/REPO --workflow collect.yml --event schedule --limit 100 --json createdAt --jq '.[].createdAt'

If the workflow is active and whole hours are simply missing, that's the scheduler dropping them rather than something in your setup. A Support ticket with those missing UTC times and a couple of run IDs around the gaps is the way to get it looked at.

You can keep the schedule trigger as a fallback alongside the external one, as long as the job is idempotent.

[Humerous]

Hi @alanjanc1995,

I wouldn't treat 5–7 runs out of 24 as something to ignore.

GitHub does document that scheduled workflows can be delayed or dropped, but you've already checked several of the usual causes, including concurrency and billing.

I'd check three things next:

1. Confirm the workflow is still enabled and the schedule exists on main.
2. Check whether the account associated with the scheduled workflow is still active.
3. Record the missing UTC execution times and raise a GitHub Support ticket with the workflow details and successful run IDs around those gaps.

If GitHub never creates a workflow run, there won't be a normal run log to investigate.

For hourly data collection, I'd also build in a way to detect and recover missed collection periods. If reliable hourly triggering is essential, an external scheduler may be a better option than relying on GitHub Actions cron alone.

Changing the cron schedule might help if the workflow has stopped because of its associated account, but I wouldn't assume it will fix repeated missing runs.

GitHub's troubleshooting documentation covers some of these cases:
https://docs.github.com/en/actions/how-tos/troubleshoot-workflows