Scheduled action never runs

[adam-uk]

Why are you starting this discussion?

Bug

What GitHub Actions topic or product is this about?

Schedule & Cron Jobs

Discussion Details

I have an old-ish free personal account, but new Repos. I've tried Private and Public repos. I can't say they previously worked, because I bever used actions before.

I can trigger either manually. They have never run on schedule. Not once!
They appears in the Workflows sidebar.
Allow all actions and reusable workflows is selected.
I'm the last commiter (the only comitter actually).
As these are new Repos the branch is main/default.
The path is .github/workflows/main.yml

I'm out of ideas.

Here's my test worflow trying the new 1vcpu runner. The private repo used ubuntu-latest

name: Simple Test
on:
schedule:
- cron: '*/9 * * * *' # Runs every 9 minutes
workflow_dispatch:

jobs:
test:
runs-on: ubuntu-slim
steps:
- name: Print Hello
run: echo "Hello! The time is $(date)"

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

[Ducanger]

I'm facing the same issue

[michaelscott-1963]

I have the same issue.

[munawwar22HU]

I am also facing a similar issue.

[adam-uk]

@Ducanger @michaelscott-1963 @munawwar22HU Could you elaborate a little please. Have you previously used them and they've stopped working, or you're trying to use them for the first time and they don't work?

[Ducanger]

@Ducanger @michaelscott-1963 @munawwar22HU Could you elaborate a little please. Have you previously used them and they've stopped working, or you're trying to use them for the first time and they don't work?

I’ve been using this for almost a year and it has always worked fine.
But over the last 3 days, it completely stopped working.

One thing I noticed: workflows/actions that were set up and successfully triggered at least once before this issue started are still running normally.
However, newly created workflows don’t get triggered at all (especially scheduled ones)

[munawwar22HU]

It worked for me, without making any specific changes.

[vhsmdev]

I’m facing the same issue. I use Actions across multiple codebases and they are working fine. Only the new repositories, as mentioned by @Ducanger, are showing the behavior described above.

[thebungeejumper]

I'm having the same problem. I can run it manually but it refuses to auto-trigger. I've tried all the things you did and still no luck. I'm starting to think the auto run feature is broken.

[joelmasters]

having the same issue. Previously working schedules just stopped working

[michaelscott-1963]

My problems started on Friday. I had no scheduled workflows previously; the ones created on Friday and Saturday either don't run or run intermittently. I create a simple workflow to test the scheduling, which only outputs the time and a dump of its payload. However, I have updated its YAML file several times since it was created, but when I look at the dump of the payload, the parameters are the ones in my original version, not the latest version.

[wannli]

See here. actions/runner#4210

[becky3]

I'm seeing the same issue: schedule workflows never trigger (even after 24 hours), while workflow_dispatch and push work fine.

name: schedule-check

on:
  push:
    branches:
      - main
  workflow_dispatch:
  schedule:
    - cron: "10 * * * *"

jobs:
  ping:
    runs-on: ubuntu-latest
    steps:
      - name: Show time in UTC and JST
        run: |
          echo "UTC: $(date -u '+%Y-%m-%d %H:%M:%S UTC')"
          TZ=Asia/Tokyo date '+JST: %Y-%m-%d %H:%M:%S %Z'

[becky3]

It was a GitHub-side issue and got rolled back.
It didn’t fix itself automatically, but after editing the YAML to re-register the workflow and running it once manually as suggested below, the schedule started working again.

https://github.com/orgs/community/discussions/185081#discussioncomment-15606848

[christianbraeunlich]

+1

[cocopuff2u]

My newly created repo is not triggering at all either but anything that has triggered before is still working

[john-wong0]

I have the same issue

[MasteraSnackin]

Based on the pattern reported here and the referenced issue actions/runner#4210, this appears to be a known issue affecting newly created scheduled workflows.

Key Findings:

The Pattern:

• ✅ Previously working scheduled workflows continue to run
• ❌ Newly created scheduled workflows (created in the last ~3 days) don't trigger automatically
• ✅ Manual triggers (workflow_dispatch) work fine
• ✅ Event triggers like push work fine

Possible Workarounds:

1. Initial Trigger Requirement: Try manually triggering your workflow at least once using workflow_dispatch. Based on reports, workflows that have been triggered at least once before this issue started continue to work.

2. Temporary Manual Trigger: Add this to your workflow temporarily:

on:
  schedule:
    - cron: '*/9 * * * *'
  workflow_dispatch:  # Manual trigger
  push:               # Or add a push trigger temporarily
    branches: [main]

3. Force Re-registration: Some users have reported success by:
   • Making a small change to the workflow file (e.g., adding a comment)
   • Committing the change
   • Manually triggering it once

What to Check:

While waiting for GitHub to resolve this:

• ✅ Verify your cron syntax is correct (use crontab.guru)
• ✅ Ensure the workflow file is in .github/workflows/
• ✅ Confirm "Allow all actions" is enabled in repo settings
• ✅ Check you have at least one commit in the last 60 days (GitHub requirement)

Note: This seems to be a platform-wide issue that started around January 23-24, 2026. GitHub staff will likely need to investigate and provide an official fix.

Would recommend upvoting the referenced issue and monitoring GitHub Status for updates.

[wannli]

Renaming "main" branch to "master" resolved the issue.

[mr-devboy]

Still no luck.
Pushing new changes or renaming "main" branch to "master" doesn't help.

[adam-uk]

It's difficult to say what has resolved it, because you can't reliably test on demand. At some point earlier today, I renamed my branch to master and checked in a change to the yml file and it began to work. 5 minute schedule typically yielding 2-3 runs an hour. I've now renamed it back to main and have just seen a successful run.

https://github.com/adam-uk/testaction/actions

https://github.com/adam-uk/testaction/blob/a31368ec8a26484bca91c205c938c5b8b6c57077/.github/workflows/main.yml

[john-wong0]

Also tried to rename to master - doesn't work

[rafael-lua]

We were having the same issue. Now the actions started to run again. The only change I made was change the default branch from develop to main, and then back to develop. No idea if this had any relation to them coming back alive or it is just something on github side.

[ping13]

Just got this message from GitHub support, still doesn't work for me - but there is hope!

Thank you for reaching out to GitHub Support!
Our engineering team identified a related change from last week that they rolled back today. Any commit pushed to the default branch should resync scheduled workflows and resolve any scheduling issues present.
Please let us know if you have any additional questions, and we can go from there

[christianbraeunlich]

Thank you for sharing! @ping13

[SrRyan]

👋 Thank you for reporting the issue with scheduled workflows not triggering. We identified a related change from last week that was rolled back today. Any commit pushed to the default branch will resync the impacted scheduled workflows and resolve any scheduling issues you may be experiencing. If you continue to experience issues with syncing schedules, please reply with a comment including the following:

1. Impacted repository
2. Workflow path and name
3. Cron syntax in the workflow

Note: Schedules that run during periods of high load (e.g., midnight UTC) may be delayed or, if load is sufficiently high, potentially dropped. Please see our docs for further information.

[bboe]

If the load is sufficiently high enough, some queued jobs may be dropped.

@SrRyan, for clarification, if the above were to happen there should still be evidence of the scheduled job being dropped, right? In the case with this issue, it doesn't seem like the job is even being queued at all.

[SrRyan]

👋 @bboe There wouldn't be evidence of the scheduled job being dropped today unfortunately as the run job does not reach far enough into the processing system to create the underlying artifacts to show back that information. This is a UX gap we have recently started some work streams to improve around this. Additionally we are working on improving the underlying performance of the scheduling jobs to be closer to our and user expectations.

[bboe]

Understandable. Thank you for the reply.

[EmpireOperating]

Not sure if it helps here, but if you’re looking for a safety net for scheduled workflows going silent: I’m building CronPulse (dead-man’s switch monitoring). You ping start/ok, and it alerts if an expected OK never arrives (missed/late/hung).

Quickstart: https://cronpulse-empire.fly.dev/docs/quickstart

If this is off-topic for this thread, ignore — just sharing in case it’s useful.