Action with CRON schedule not being triggered or scheduled

[smistry7]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Schedule & Cron Jobs

Discussion Details

Description I have a GitHub Actions workflow at .github/workflows/sync-signgpt-publications.yml in repository cogvis-cvssp/cogvis-cvssp.github.io that includes a schedule trigger, but the scheduled runs never start.

What I’ve verified:

• The workflow file is on the default branch.
• The default branch is master.
• The workflow does trigger correctly on push to master.
• The workflow also runs correctly with workflow_dispatch.
• I have tested different cron times, and none of them have produced a scheduled run.
• The cron syntax currently used is valid: 54 8 * * *.

Current workflow trigger block:

on:
  schedule:
    - cron: "54 8 * * *"
  workflow_dispatch:
  push:
    branches: [master]
    paths:
      - scripts/update_signgpt_publications.py
      - .github/workflows/sync-signgpt-publications.yml

Relevant context:

• The repository is https://github.com/cogvis-cvssp/cogvis-cvssp.github.io
• The workflow page is https://github.com/cogvis-cvssp/cogvis-cvssp.github.io/actions/workflows/sync-signgpt-publications.yml
• Since workflow_dispatch and push both work, the workflow file and job itself appear to be valid.
• The problem seems isolated to the schedule event not firing at all.

Request: Please investigate why the schedule trigger is not starting runs for this workflow, despite the workflow being present on the default branch and other triggers working as expected.

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

[SandupaAbeywardana]

Since push and workflow_dispatch both work, the workflow itself is fine. It's the schedule that isn't getting picked up. A few things that usually sort this out:

1. In the Actions tab, open the workflow, hit the ... menu → Disable workflow, then enable it again. This makes GitHub re-register the schedule and it fixes it more often than not.
2. If that doesn't work, change the cron slightly (even one minute) and push to master. The schedule is read from the latest commit on the default branch, so a fresh commit to the workflow file can kick it back into place.
3. Keep in mind cron runs in UTC, so 54 8 * * * is 08:54 UTC, which might not match when you're checking.
4. Check that whoever last edited the cron line still has access to the repo. Scheduled runs are tied to that user, and if they left the org or lost access the runs can stop without any error.

Also, scheduled runs can be late (sometimes up to an hour) when Actions is busy, so give it a day after changing something before calling it broken.

[smistry7]

I've attempted disabling and enabling to no avail. This workflow has not run over multiple days with multiple different CRON settings.

[CalicheOrozco]

Adding a few things to check on top of the suggestions above, since push and workflow_dispatch working rules out most syntax problems:

1. Filter the runs list by event. On the workflow page, filter with event:schedule. If nothing shows up at all, the schedule was never registered. If runs show up but failed or were skipped, it's a different problem.

2. Look for a banner on the workflow page. GitHub sometimes shows a message like "This scheduled workflow is disabled because there hasn't been activity in this repository for 60 days". Disabling and re-enabling the workflow clears it.

3. Check who made the last commit that touched the cron line. Scheduled runs are tied to the actor who last modified the schedule. If that commit came from a bot, a GitHub App, or the workflow itself (for example, a sync job that commits with GITHUB_TOKEN), try making a small manual edit to the cron line from a regular user account and pushing it to master.

4. Confirm the repo isn't a fork. Scheduled workflows don't run in forks by default until Actions is explicitly enabled there.

5. Check the org's Actions settings. Make sure there's no policy under Settings → Actions that limits which workflows or events can run.

6. Pick a less busy time. 54 8 * * * is already a good choice since it avoids the top of the hour, but scheduled runs can still be delayed or dropped under heavy load. Give it at least 24 hours after each change.

If none of this helps, it's worth opening a ticket with GitHub Support (support.github.com). They can see whether the schedule is registered on their side, which we can't check from the UI.

[smistry7]

Nothing appears with event:schedule, and I've tried all the other options unfortunately. It still doesn't get triggered

[CalicheOrozco]

Thanks for checking. If event:schedule shows nothing at all, the schedule is never being registered, so let's narrow down whether it's this workflow or the whole repo:

1. Add a minimal test workflow. Create a new file, for example .github/workflows/schedule-test.yml, and push it to master:

name: Schedule test
on:
  schedule:
    - cron: "*/15 * * * *"
jobs:
  ping:
    runs-on: ubuntu-latest
    steps:
      - run: echo "schedule works"

Give it an hour or two. If this one fires, the problem is specific to your original workflow. If it doesn't fire either, something at the repo or org level is blocking scheduled events.

2. If the test works, rename the original file. For example, change sync-signgpt-publications.yml to sync-publications.yml. GitHub treats it as a new workflow with a new ID, which can clear a schedule that got stuck in a bad state on their side.

3. If the test doesn't work either, it's almost certainly something only GitHub can see. Open a ticket at support.github.com. Include the repo, the workflow URL, the fact that event:schedule has never produced a run, and the result of the test workflow. That makes it much quicker for them to find the issue.

Once you've tried it, please delete the test workflow (or change it to a less frequent cron) so it doesn't use up minutes.

[ps2builds]

Ran into the exact same thing with one of my repos last month. Two extra things worth checking: GitHub automatically disables scheduled workflows after 60 days without any repository activity, and it shows a banner on the workflow page when that happens — your repo looks fairly quiet so that's plausible. Also make sure the cron edit actually made it onto the default branch; the scheduler only reads the workflow file from master, so changes sitting in an unmerged branch never register. In my case the fix was tweaking the cron by one minute and pushing straight to master, then waiting a day — the next scheduled run appeared.

[smistry7]

Had my first scheduled build (days late it seems) going to close this and attribute it to this issue: https://github.com/orgs/community/discussions/156282