I'm having trouble with a scheduled GitHub Actions workflow in a private repository.

[shchebetiuk2003-dotcom]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

ARC (Actions Runner Controller)

Discussion Details

Unfortunately, the repository and source code are private, so I cannot share the full project. However, the workflow file is shown below exactly as it exists in the repository:

name: Training Poll Bot

on:
schedule:
- cron: '0 */6 * * *'
workflow_dispatch:

jobs:
run-bot:
runs-on: ubuntu-latest

steps:
  - name: Checkout repository
    uses: actions/checkout@v4

  - name: Set up Python
    uses: actions/setup-python@v5
    with:
      python-version: '3.11'

  - name: Install dependencies
    run: pip install -r requirements.txt

  - name: Run bot
    env:
      BOT_TOKEN: ${{ secrets.BOT_TOKEN }}
      CHAT_ID: ${{ secrets.CHAT_ID }}
    run: python bot.py

trigger cron

Additional information:

Repository is private.
Default branch is main.
Workflow file is located in .github/workflows/.
GitHub Actions are enabled.
Secrets are configured correctly.
Manual runs work perfectly.
The workflow completes successfully and the Python script executes as expected.
The workflow has been committed directly to the main branch.

The issue is that I only see runs started manually via workflow_dispatch ("Manually ran by ...").

I have never seen a run triggered by schedule.

Since the code is private, I cannot provide access to the repository, but based on the workflow above, is there anything obvious that could prevent the scheduled trigger from running?

Are there any known delays, restrictions, or settings that I should check for scheduled workflows in private repositories?

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

[gistrec]

Your config actually looks fine — since manual runs complete successfully, the file parses and is on main, so indentation and branch placement aren't the issue. Two things that usually cause exactly this (manual works, schedule never fires):

1. 0 */6 * * * runs at minute :00 — a peak-load window where GitHub routinely delays scheduled runs and, under high enough load, drops them silently. Move it off the hour, e.g. cron: '7 */6 * * *'.
2. Schedules can quietly stop being registered (more common on low-activity private repos). Push any trivial commit to main to force a resync, then check the Actions tab filtered by event:schedule after the next non-:00 window.

If it still never fires after that, it's most likely a backend issue worth a response from support team

[TheButterZone]

I'm having effectively the same non-firing cron issue with public https://github.com/TheButterZone/thebutterzone.github.io/blob/main/.github/workflows/check-btc.yml even after the trivial commit to main (added one blank line to readme).

Let me know if I should make a new discussion post & cut/paste all this over to it:

Jun 6, 8:26 PM UTC was the last failed action of workflow_dispatch, since then, there have been some successes, both workflow_dispatch: & scheduled, until... actions?query=event%3Aschedule shows nothing whatsoever after the last scheduled success Today at 2:15 AM UTC.

The only scheduled successes before that were at 11:54 PM UTC, 10:54 PM UTC, 9:55 PM UTC... which means cron was so backed up it took almost a whole hour 75% of the times it was successful? Wonder why 2:15 AM UTC was the outlier that immediately preceded no more scheduled action runs, and the 12 AM & 1 AM ones presumably were skipped by cron out of the schedule, with the 2 AM one taking only 15 minutes as a tease before I got ghosted?

Ok, fair, I should have set the minute later than top of the hour, so I did: first commit with "21 * * * *" deployed ~5:07 AM UTC.

It is now 8:38 AM UTC (as of this update comment). Still not even a failed action for what should have been a bunch of runs rescheduled to ~hourly:21 minutes after the hour. Only workflow_dispatch: runs are successful, it's like GitHub's cron just said "nope, not doing "0 * * * *" or "21 * * * *" or anything for this user anymore, ghosting time".

Oops, needed to refresh harder, cron snuck in a successful scheduled at 08:31 AM UTC - after 6 hours, 16 minutes, of nothing!

I really don't want to play a cat & mouse commit game with this, but should my final test be replacing "21 * * * *" with "50 * * * *" so it enters the cron queue just before most of the previously successful times, instead of sitting in queue for about a full hour or 30 minutes... or forever?

I have no other branch but main & no commit that should have been a breaking one, to that or any other file, nor even a settings change...

And FWIW

Billable usage
View details

$0 Total billable usage after subtracting discounts from consumed usage
$0.95 consumed usage-$0.95 discounts

P.S. My state machine stores last-seen timestamps from its query source & each run is idempotent, so the delay is just annoying instead of unsafe.

[tanvishinde017]

Nothing in the workflow you shared immediately stands out as preventing scheduled runs. Since workflow_dispatch works, the workflow itself and your secrets are probably fine.

A few things worth checking:

• Make sure the workflow syntax is actually:

on:
  schedule:
    - cron: '0 */6 * * *'
  workflow_dispatch:

Improper indentation can cause the schedule to be ignored.

• Scheduled workflows always run from the repository's default branch (main in your case). Confirm the workflow file exists there.

• Scheduled jobs are not guaranteed to start exactly on time. Delays are normal, especially around busy periods.

• If the repository has been inactive for an extended period, scheduled workflows may be automatically disabled. Check the Actions tab for any banner mentioning disabled workflows.

• Verify that Actions are enabled at both the repository and organization level.

• Try changing the cron temporarily to something more frequent (for example every 15 minutes) to confirm whether any scheduled events are being generated.

• Check whether the repository owner recently changed, as ownership changes can sometimes affect scheduled workflows until the workflow is re-enabled.

If everything above looks correct and you still never see a run whose trigger is schedule, this may be a platform-side issue rather than a problem with your workflow. In that case, sharing the repository settings related to Actions (without exposing private code) could help narrow it down further.