Scheduled workflow never triggers

[kdefrance]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

ARC (Actions Runner Controller)

Discussion Details

Subject: Scheduled workflow never triggers, but manual execution succeeds

My private repository is private

Workflow: .github/workflows/account-deletion.yml
Default branch: main
Schedule: '3-59/5 * * * *'

The workflow is enabled. Its repository variable ACCOUNT_DELETION_SCHEDULE_ENABLED is set to true.

Manual workflow_dispatch execution succeeds, including the authenticated server callback. However, no scheduled execution has appeared during more than two hours of observation on October 20, 2026.

I changed the cron schedule through a commit from my own account and disabled/re-enabled the workflow. No scheduled execution has appeared. A separate verification workflow runs successfully on push.

Could you investigate why scheduled events are not triggering for this workflow, including its schedule registration and associated actor?

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

[ronitgupta138]

The issue is due to the non-standard step-range syntax in your cron expression:

1. Cron Range-Step Parser Limitation

While standard POSIX / Linux crontab implementations parse syntax (e.g. ), the GitHub Actions schedule parser uses a strict subset of cron format. Range-step combinations with non-zero offsets frequently fail server-side validation or are silently ignored by the scheduler backend.

Solution: Use Explicit Minute Enumeration or Standard Step

To reliably trigger every 5 minutes with your 3-minute offset, enumerate the minute values explicitly:

Or if an offset isn't strictly necessary, use the standard step interval:

2. Additional Checklist for Private Repositories

Since your repository is private:

• Activity Pause: GitHub automatically pauses scheduled workflows in repositories with no commit activity for 60 days.
• Spending Limit / Quota: Verify under Settings > Billing & plans > Spending limit that Actions minutes have not reached their limit, as scheduled runs in private repositories are dropped when monthly minutes are depleted.

[tp322d]

Per the Actions docs, the cron operators include - (range) and / (step). Their only example is a start-plus-step form (20/15), and they never show your exact combined form 3-59/5, so I can't call it confirmed. The docs also say scheduled workflows run only from the workflow file on the default branch, the shortest interval is 5 minutes, and the schedule event can be delayed under high load, with some queued jobs possibly dropped. As an experiment, you could commit the same schedule as an explicit list (3,8,13,18,23,28,33,38,43,48,53,58) and see whether runs appear. If they still don't, the scheduler's state isn't visible from your side, so only GitHub can check it.