Cron job never being triggered

[shwethanathan]

🏷️ Discussion Type

Bug

Body

I'm unable to get scheduled GitHub Actions workflows to execute.

Manual runs (workflow_dispatch) work perfectly, but GitHub never creates workflow runs with the schedule event.

This occurs across multiple repositories, including a minimal reproduction repository.

Minimal reproduction

name: Test Cron

on:
  schedule:
    - cron: "*/5 * * * *"
  workflow_dispatch:

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - run: |
          echo "Ran!"
          date
Repositories

BookMyShow project

https://github.com/shwethanathan/bms-ticket-notifier

Minimal reproduction

https://github.com/shwethanathan/test-wf

Details:

• Repository exists on my personal GitHub account.
• Default branch is main and all changes to the workflow are committed directly to main.
• Repository is recently committed to (i.e not stale)
• Repository is not archived.
• Repository is not disabled.
• Tested with both public and private visibility.
• Workflow syntax is valid.
• Workflow appears under the Actions tab.
• Manual workflow_dispatch runs complete successfully.
• GitHub API reports the workflow state as active
• There are no workflow runs whose event is schedule.
• GitHub-hosted runners are available.
• Actions are enabled for the repository.
• Workflow permissions are configured correctly.
• The workflow is enabled (not disabled due to inactivity).
• Waited well beyond the cron interval.
• Tried multiple cron schedules (*/5, */8, */10).
• Modified and recommitted the workflow multiple times.
• Created an entirely new repository with only the minimal workflow above.

Guidelines

• I have read and understood this category's guidelines before making this post.

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

[dreynox]

Hi @shwethanathan ,
Your workflow looks correct, so this doesn't appear to be a YAML configuration issue. One thing to keep in mind is that GitHub doesn't guarantee scheduled workflows will run at the exact cron time—they can be delayed or even skipped during periods of high load, especially for schedules like */5. However, if no schedule event is ever being created across multiple repositories, including a minimal reproduction, it sounds more like a platform-side issue than a repository-specific one.

Hopefully, a GitHub staff member can investigate whether there's an issue with scheduled workflows on your account or confirm if this is a broader service problem.

[ECD5A]

This appears to have recovered, and the current repository data provides a useful clue that the YAML was not the root cause.

I checked shwethanathan/bms-ticket-notifier through the GitHub REST API. It now has multiple successful runs whose event is explicitly schedule, including runs at:

• 2026-07-25T18:00:30Z
• 2026-07-25T18:06:38Z
• 2026-07-25T18:39:52Z
• and continuing scheduled runs afterward

The four current workflows at minutes 3, 18, 33, and 48 are all active and are producing scheduled runs. The linked shwethanathan/test-wf repository currently returns 404, so it can no longer be inspected publicly.

This means there is no configuration change needed for the current BMS workflows: GitHub eventually registered/queued their schedules. It is consistent with GitHub's documented behavior that scheduled events can be delayed during high load and, under sufficiently high load, queued jobs may be dropped. GitHub specifically recommends avoiding the start of the hour. See Events that trigger workflows — schedule.

You can verify only cron-created runs with:

gh run list --repo shwethanathan/bms-ticket-notifier --event schedule

One important design point: schedule is suitable for best-effort periodic work, but it is not an exact scheduler or availability guarantee. If the ticket checker truly must execute every few minutes without missed intervals, use an external scheduler that calls workflow_dispatch or repository_dispatch, and make the job idempotent. Otherwise, the current staggered off-hour minute values are a sensible way to reduce contention.