I'm having trouble with a scheduled GitHub Actions workflow in a private repository. #197690
Replies: 4 comments
-
|
💬 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 ⏩
Where to look to see what's shipping 👀
What you can do in the meantime 💻
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. ⭐ |
Beta Was this translation helpful? Give feedback.
-
|
Your config actually looks fine — since manual runs complete successfully, the file parses and is on
If it still never fires after that, it's most likely a backend issue worth a response from support team |
Beta Was this translation helpful? Give feedback.
-
|
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 $0 Total billable usage after subtracting discounts from consumed usage 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. |
Beta Was this translation helpful? Give feedback.
-
|
Nothing in the workflow you shared immediately stands out as preventing scheduled runs. Since A few things worth checking:
on:
schedule:
- cron: '0 */6 * * *'
workflow_dispatch:Improper indentation can cause the schedule to be ignored.
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. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
🏷️ 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
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?
Beta Was this translation helpful? Give feedback.
All reactions