Github Scheduled Actions not Triggering

[pr-ghub]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

ARC (Actions Runner Controller)

Discussion Details

In order to test the Github Actions, I created an extremely simple file in .github/workflows/schedule_test.yml. This file is as follows:

name: Schedule Test

on:
  schedule:
    - cron: "*/5 * * * *"

jobs:
  ping:
    runs-on: ubuntu-latest
    steps:
      - run: echo "schedule fired at $(date -u)"

It still does not trigger. I have checked my Actions Settings, ensured that I have a commit within 60 days, am on the main branch and have basically looked through all suggested answers that I could find and I tick the boxes everywhere. Hence I would like to know what am I doing wrong?

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

[antoniorotundo2]

The YAML itself looks correct, and you have already covered the two most common gotchas, a commit within 60 days and being on the default branch, so this is very likely a timing issue rather than a configuration one.

GitHub documents scheduled workflows as best effort rather than guaranteed: the schedule event can be delayed during periods of high load, and high load specifically includes the start of every hour, with delays commonly reported in the 5 to 30 minute range and occasionally longer. Every 5 minutes is also the shortest interval GitHub supports, which makes it the pattern most exposed to that delay or to being silently dropped during a busy window, since it is competing with every other repository on the platform running the same minimal interval. Eleven minutes since creating the workflow is not long in that context, especially if the very first scheduled minute happened to land during a high-load window.

Two things would tell you which case you are actually in. First, add workflow_dispatch: alongside the schedule trigger and run it manually from the Actions tab, if that succeeds the workflow itself is fine and the issue is purely the schedule timing, not the YAML or permissions. Second, check the Actions tab specifically for this workflow rather than just the repository's general Insights, if there are zero runs at all rather than runs that simply started late, that points toward the schedule event being dropped rather than delayed, which is consistent with using the tightest possible interval during a high-load period.

If you need something closer to on-time firing than GitHub's schedule event can guarantee, the common workaround is treating schedule as a fallback rather than the primary trigger, and having an external scheduler call the workflow through workflow_dispatch or the REST API at the exact minute you need, since dispatch events are not subject to the same load-based delay.

If my answer was helpful to you, please consider marking it as the correct answer, thanks.

[mhmdwaelanwr]

The YAML itself looks valid. */5 * * * * is also the shortest supported schedule interval on GitHub Actions, so I would not focus on the cron syntax.

One thing I would check first is whether this repository is a fork.

GitHub disables scheduled workflows by default on public forks. If it is a fork, go to Actions, select the workflow, open the ... menu and make sure the workflow is enabled.

I would also verify that main is not just the branch you are working on, but the repository's actual default branch. Scheduled workflows only trigger when the workflow file exists on the default branch, and scheduled runs always use that branch.

Also, this test is not using ARC at all:

runs-on: ubuntu-latest

That uses a GitHub-hosted runner. So an ARC configuration problem would not explain this particular test failing to create a run.

For debugging, I would temporarily use:

name: Schedule Test

on:
  workflow_dispatch:
  schedule:
    - cron: "7,22,37,52 * * * *"

jobs:
  ping:
    runs-on: ubuntu-latest
    steps:
      - run: echo "schedule fired at $(date -u)"

Then:

1. Commit that exact file to the repository's actual default branch.
2. Run it once manually with workflow_dispatch.
3. Leave it for at least several scheduled windows.
4. Check Actions → Schedule Test and confirm the workflow itself is enabled.

I used non-round minutes deliberately because GitHub documents that scheduled events can be delayed during periods of high load, especially near the start of the hour. However, if you get zero runs across many 15-minute windows, normal scheduler delay is unlikely to explain it.

If manual dispatch works, the file is definitely on the default branch, the workflow is enabled, the repository is not an inactive/disabled fork case, and scheduled runs still never get created, I would report it to GitHub Support as a scheduler-registration issue and include:

• repository URL;
• workflow path;
• commit SHA;
• actual default branch;
• whether the repository is a fork;
• expected UTC trigger times;
• confirmation that workflow_dispatch succeeds.

So I don't think there is anything obviously wrong with the workflow shown here. The main things I would investigate are workflow disabled state, fork status, and whether main is truly the repository's default branch.