Scheduled GitHub Actions workflow is active but creates no runs

[david-leppek]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

ARC (Actions Runner Controller)

Discussion Details

A scheduled workflow in my private repository is enabled on the default branch (main), but no scheduled runs are appearing.

Schedule:

schedule:
  - cron: '*/15 * * * *'

On October 15, 2026, we checked several expected schedule times, including 18:30, 18:45, 19:00, 19:15, and 20:15 UTC. Successful repository-wide Actions API queries filtered by event=schedule returned no runs.

What we verified:

• The repository is active and Actions is enabled.
• The workflow state is active.
• The workflow containing the schedule is on main.
• Manual workflow_dispatch runs work.
• GitHub Status reported all systems operational during our checks.

Some API requests failed intermittently from our environment, but the successful schedule-history queries returned empty results. We have not established the cause.

How can we determine whether GitHub is evaluating the schedule, and whether events are delayed, suppressed, or rejected? Are there additional configuration or account checks we should perform?

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

[4waiz]

Two things in the schedule docs explain most "active but never runs" cases:

1. The schedule is tied to whoever last changed the cron line. A commit that changes the cron schedule, made by a user with write access, (re)activates a scheduled workflow and makes that user its actor. With Enterprise Managed Users, scheduled workflows don't run at all once that actor has been deprovisioned. workflow_dispatch keeps working in that situation, because manual runs use whoever triggers them.
2. Top-of-the-hour load. */15 fires at :00, :15, :30 and :45. The docs say scheduled runs "can be delayed during periods of high loads", that "high load times include the start of every hour", and that "some queued jobs may be dropped".

You can address both with one commit: have someone with write access change the cron line on main and move it off the round minutes:

on:
  schedule:
    - cron: '7,22,37,52 * * * *'   # every 15 min, avoiding :00/:15/:30/:45
  workflow_dispatch:

Then check after the next slot:

gh api "repos/OWNER/REPO/actions/runs?event=schedule&per_page=5" \
  --jq '.workflow_runs[] | [.created_at, .name, .status] | @tsv'

If runs still don't appear, run gh workflow view <workflow-file> --yaml to confirm that the version GitHub reads from main contains the schedule block you expect, and that the file lives in .github/workflows/ on the default branch.

Since you tagged ARC: runner availability doesn't stop schedule events from being created. With no ARC runners online you'd see runs stuck in queued, not zero runs, so an empty event=schedule list points at the trigger rather than at your runners.

[6Hs-nRK]

  <img src="https://latex.codecogs.com/svg.image?\huge&space;{\color{&hash;C39026}\mathrm{PR}{\color{&hash;966600}\O}\mathrm{XY}\;\mathrm{IP}}" width="280px"