Hourly scheduled workflow suddenly skips multiple consecutive triggers

[jessie-mele]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Schedule & Cron Jobs

Discussion Details

My hourly scheduled workflow has suddenly stopped triggering reliably.

The workflow file is .github/workflows/hourly-jobs.yml on the repository’s default main branch. It is enabled and contains:

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

There are no workflow conditions or concurrency settings that would suppress a run.

A manual workflow_dispatch run completed successfully at 12:33 PM EDT, confirming that the workflow and job itself work. However, GitHub did not create scheduled runs at 1:17, 2:17, 3:17, 4:17, or 5:17 PM EDT. No failed, queued, cancelled, or skipped runs appear for those times—the runs were never created.

Before changing the schedule to 17 * * * *, the workflow used 0 * * * * and had also begun skipping several consecutive hourly runs. Scheduled runs that did occur were sometimes substantially delayed, including starts at 6:35 AM and 10:52 AM.

The workflow previously ran every hour reliably. The workflow is active, exists on the default branch, and manual dispatch continues to work.
<img width="946" height="617" alt="Screenshot 2026-09-08 at 5 29 30 PM" src="https://github.com/user-attachments/assets/005d372c-64f6-4c1c-91d3-fac46220536c" />

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

[TongyiDai]

Your evidence rules out the workflow job itself: if workflow_dispatch succeeds but no scheduled run object is created, the failure is before runner assignment.

GitHub documents two important properties of schedule: it runs from the latest commit on the default branch, and scheduled events may be delayed—or under sufficiently high load, dropped. The busiest period is the start of the hour. You already moved to minute 17, which is sensible, but five consecutive missing events is beyond ordinary timing drift.

I would capture these checks before changing anything else:

gh api repos/OWNER/REPO/actions/workflows/hourly-jobs.yml \
  --jq '{id,path,state,created_at,updated_at}'

gh run list --repo OWNER/REPO \
  --workflow hourly-jobs.yml --event schedule --limit 20

gh api repos/OWNER/REPO \
  --jq '{default_branch,archived,disabled}'

If the workflow state is not active, toggle it once:

gh workflow disable hourly-jobs.yml --repo OWNER/REPO
gh workflow enable hourly-jobs.yml --repo OWNER/REPO

Then make a real edit to the cron line on the default branch (for example 17 to 23) to force schedule re-registration. Do not use repeated empty commits as a permanent workaround.

If no run object appears after several windows, report the workflow ID, repository, UTC windows, and the successful manual run URL to GitHub Support. There is no repository-side log for an event that the scheduler never emitted. For anything requiring hourly delivery guarantees, keep the external scheduler calling workflow_dispatch; GitHub's native cron is explicitly best-effort rather than an SLA scheduler.

Reference: https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax#onschedule

[jessie-mele]

Thank you for the reply! I ran the three checks.

The workflow is active:

{
"created_at": "2025-01-16T16:18:53.000-05:00",
"id": "xxxxxxxxx",
"path": ".github/workflows/hourly-jobs.yml",
"state": "active",
"updated_at": "2025-05-27T13:22:44.000-04:00"
}

The repository is also active and the workflow is on the correct default branch:

{
"archived": false,
"default_branch": "main",
"disabled": false
}

A manual workflow_dispatch run completed successfully at approximately 12:33 PM EDT on September 8. I also made a real edit to the cron line on main, changing it from:

• cron: '0 * * * *'

to:

• cron: '17 * * * *'

However, the schedule is still running only once every few hours. These are the exact creation times returned by gh run list, filtered to hourly-jobs.yml and the schedule event:

2026-09-08T05:35:24Z
2026-09-08T10:35:04Z
2026-09-08T14:52:15Z
2026-09-08T21:50:13Z
2026-09-09T00:12:40Z
2026-09-09T04:39:47Z
2026-09-09T09:43:11Z
2026-09-09T14:34:34Z
2026-09-09T18:34:17Z
2026-09-09T21:41:00Z

Every scheduled run that GitHub creates completes successfully. The issue is that most expected hourly scheduled run objects are never created. Over approximately 40 hours, only 10 scheduled runs were created instead of approximately 40.

Since the workflow state is already active, I have not disabled and re-enabled it yet. Is toggling it still the recommended next step?

[TongyiDai]

Thanks — those timestamps materially narrow it down. Because GitHub is still creating some schedule events and every created run succeeds, this is not a workflow, runner, branch, or permissions failure. The missing hourly run objects point to scheduler delivery/registration upstream of the workflow.

A single disable/enable cycle is still reasonable as a low-risk re-registration test, but I would do it only once and record the exact UTC time:

gh workflow disable hourly-jobs.yml --repo OWNER/REPO
gh workflow enable hourly-jobs.yml --repo OWNER/REPO

Then make no other workflow changes for at least several expected windows. Repeated toggling would make the evidence harder to interpret.

Given the observed 10/40 delivery rate, I would not rely on native schedule for hourly guarantees even if the toggle improves it. Keep the external scheduler calling workflow_dispatch as the operational workaround. For GitHub Support, include the workflow ID, the successful manual run, the complete expected-vs-observed UTC table, and emphasize that missing slots have no run object at all. That distinguishes scheduler delivery loss from queued/dropped jobs or runner failures.

If the disable/enable cycle changes the delivery rate, please update the thread; that result would help distinguish stale schedule registration from a broader scheduler issue.

[jessie-mele]

Thank you. I’ll perform one disable/enable cycle, record the exact UTC time, and then leave the workflow unchanged while monitoring several expected windows. One clarification: there is currently no external scheduler; this workflow has historically relied only on GitHub’s native schedule. I’ll update the thread with the observed delivery rate after the test.