GitHub Actions schedule events stopped being generated – workflow_dispatch still works

[Kudd3l]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Schedule & Cron Jobs

Discussion Details

I'm experiencing an issue with scheduled GitHub Actions workflows in my private repository.

Since November 9, 2026, scheduled workflows have stopped triggering. Manual workflow_dispatch runs continue to work successfully.

What I have verified

• All workflows are enabled.
• All scheduled workflow files are present on the default branch (main).
• Manual workflow dispatch works successfully.
• Cron expressions were changed by the repository owner on November 9, but this did not restore scheduling.
• A separate diagnostic workflow was added with no secrets, external API calls, or application dependencies.

Despite multiple scheduled intervals passing, no schedule runs were created.

Is anyone else experiencing this issue?

Has anyone found a reliable way to restore scheduled event generation, beyond changing the cron expression and committing it to the default branch?

[helmipradita]

When workflow_dispatch works but schedule events stop firing, the issue is almost always a desynchronization in GitHub's internal cron scheduler registry rather than an error in your YAML file.

Here is why this happens and the step-by-step methods to force GitHub's scheduler daemon to re-register your cron timers:

---

1. Cycle the Workflow State (Hard Refresh the Scheduler)

Simply committing changes to the YAML file does not always trigger the internal workflow.schedule_register hook. You can force an explicit re-registration via the UI:

1. In your repository, click the Actions tab.
2. In the left-hand sidebar, select the specific scheduled workflow.
3. On the right side of the workflow banner, click the ... (more options) button.
4. Select Disable workflow.
5. Wait 30 to 60 seconds.
6. Refresh the page and click Enable workflow.

This sends a direct event to the Actions scheduler backend to rebuild the cron entry for that workflow.

---

2. Verify State via GitHub CLI / REST API

Sometimes the GitHub web UI displays a workflow as active even when the internal API flag has slipped into disabled_inactivity or disabled_manually:

1. Check the true backend status of your workflows using the GitHub CLI:

   gh workflow list --all

2. If the status is not active, or to explicitly force an update:

   gh workflow enable <workflow-name-or-id>

---

3. Shift the Cron Minute Offset

GitHub's scheduler runs under heavy queue pressure during top-of-the-hour intervals (00 * * * * or 00 00 * * *). Under high platform load, schedule runs that miss their execution window by more than a few minutes can be dropped entirely.

If your cron expression uses 0 for the minute field, adjust it to an uncommon minute offset (e.g. 17 6 * * * instead of 0 6 * * *).

---

4. Verify the Default Branch Setting

GitHub Actions only generates scheduled runs from the repository's designated default branch.

• Go to Settings → General.
• Under Default branch, ensure that the repository's default branch is set to the branch containing the latest workflow file (e.g., main). If the default branch was ever changed or points elsewhere, scheduled runs will not trigger.

[RanaKhan77]

schedule stopped firing while workflow_dispatch worked fine. After checking the docs and talking to a few folks, here's what I found.

The docs say the schedule event can be delayed during high load on GitHub Actions, especially around the top of every hour. If load is high enough, some queued jobs get dropped. Since late August 2026 there's a documented cluster of multi-hour schedule delays — a two-repo control experiment showed it's platform-level, not something in my workflow config.

Two things fixed it:

1. Force a resync — push any commit to the default branch. GitHub staff confirmed this resolves impacted scheduled workflows.
2. Avoid the top of the hour — I switched from 0 * * * * to 17 * * * * and it's been stable since.

Also: scheduled workflows auto-disable after 60 days of repo inactivity, and GitHub emails first (check spam).

Control-experiment thread: https://github.com/orgs/community/discussions/207346

If you're on a critical path, I'd add a workflow_dispatch trigger as a fallback until this stabilizes.

[Kudd3l]

Thanks to both of you for taking the time to look into this and share your suggestions!

I appreciate the detailed explanations and the pointers to the related discussions. I’ve now also tried disabling and re-enabling the diagnostic workflow, as suggested, but unfortunately that hasn’t made any difference.

The issue is still ongoing. As of November 12, only five scheduled runs had been triggered across all workflows since midnight UTC. The diagnostic workflow, which is scheduled to run every 15 minutes, had only run twice by 10:33 UTC.

So far, manual workflow_dispatch runs continue to work perfectly, while scheduled runs remain very sporadic.

Thanks again for your help! I’ll keep monitoring the situation and will share any further findings.

[Praveen-Suthar-08]

Same thing here. Manual run works but schedule is not firing, so I think its a github side problem, not your yaml. Docs say scheduled runs can be delayed or dropped when load is high.

What worked for me: change the cron to an odd minute like 7,37 * * * * and push a small commit to main. Also check githubstatus.com.

If you need it to run for sure, call the workflow_dispatch API from cron-job.org, that part works for you.