Scheduled workflow triggers stopped firing on a private repo, but manual workflow_dispatch is operating as expected.

[Smartercarter01]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

ARC (Actions Runner Controller)

Discussion Details

I'm seeing what looks like the same class of issue reported in several other discussions here, but I'm posting my own case since it's ongoing and I've been bashing my head against a wall trying to fix it.

My repo is private, if that matters.
My first workflow fired successfully on schedule once at 2026-07-28 22:45:16 UTC.
Zero scheduled runs since, despite 8+ expected cron matches through 2026-07-29 08:35 UTC.

Manual workflow_dispatch on the same workflow succeeded every time.

My second workflow, added 2026-07-29 02:45 UTC, had zero scheduled runs, ever, despite 5+ expected cron matches since it was added.
Manual workflow_dispatch succeeded every time (2 attempts).

I am no expert so I may have tested these incorrectly, but HOPEFULLY I have ruled out the following.

Workflow validity/state. Both show "state: active" via the Actions API.
Repo Actions permissions "Allow all actions and reusable workflows," no disabled banner, no spending-limit notice.
Billing issues would also block manual dispatch, which works fine.
Stale schedule registration — pushed a commit touching both workflow files on 2026-07-29 ~07:45 UTC. And, shocker, the next two scheduled windows for both workflows still didn't fire.

No clue why the scheduler seems to have dropped this repo's schedule registrations. Any help is appreciated!

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

[jrb00013]

A few things commonly look exactly like what you’re describing: schedule goes quiet while workflow_dispatch still works.

Manual dispatch and cron are different trigger paths. If dispatch succeeds, billing / Actions-disabled / “workflows blocked” are usually not the root cause — the scheduler path (or the YAML the scheduler is actually reading) is.

1. Confirm the schedule is on the branch GitHub actually uses

Scheduled workflows only run from the default branch (usually main/master).
If you edited cron on dev / a feature branch, or the workflow file on default still has an old/empty on.schedule, you’ll see:

• workflow_dispatch works (you can run from any branch in the UI)
• cron never fires (scheduler only watches default)

Check: open the workflow file on the default branch in the GitHub UI and verify the on: block there matches what you think you deployed.

2. Cron / schedule config mistakes that look “dead”

• Cron is UTC, not local time — easy to “miss” windows you expected.
• Very frequent crons get skipped/delayed under load; GitHub does not guarantee exact-minute execution.
• Invalid or overly clever expressions / duplicate workflow names can leave a workflow active in the API but not scheduling as you expect.
• After creating a new workflow, the first scheduled run can lag; still, zero fires across many windows usually means branch/config mismatch, not just lag.

3. “Some jobs only run on manual” inside the same workflow

Even when the workflow is scheduled, individual jobs can opt out of schedule via if::

on:
  schedule:
    - cron: '0 * * * *'
  workflow_dispatch:

jobs:
  build:
    # runs on both
    runs-on: ubuntu-latest
    steps: [...]

  deploy:
    # ONLY when you click Run workflow
    if: github.event_name == 'workflow_dispatch'
    runs-on: ubuntu-latest
    steps: [...]

Symptoms: schedule “does nothing useful” / no deploy job, but manual looks fine. Check every job’s if: for github.event_name, github.ref, environment protection rules, or required secrets that fail closed on schedule.

4. Other gotchas worth ruling out

• Path filters / concurrency / cancel-in-progress interacting oddly with scheduled runs
• Workflow disabled specifically for schedule history (Actions tab → workflow → “…” → ensure it’s enabled; API state: active is necessary but not always the whole story)
• Private-repo / org policy that still allows manual but throttles or drops schedules (rarer, but exists in some enterprise setups)
• Looking at the wrong workflow run list filter (event = schedule vs workflow_dispatch)

What I’d do next (quick checklist)

1. On default branch, paste the exact on: block from the two workflow files.
2. In Actions, filter runs by event schedule for those workflows — confirm zero, not “hidden.”
3. Search both YAML files for if:.*workflow_dispatch / github.event_name.
4. Temporarily simplify to a single hourly cron on default with one trivial job (no if:) and wait 1–2 windows.
5. If a bare cron on default still never appears, it’s likely a platform scheduler registration issue → open a ticket with GitHub Support and include repo name + expected cron UTC times + that dispatch works.

Most of the time on private repos this ends up being #1 (wrong branch) or #3 (job-level manual-only if:), not Actions being “broken” globally.

[Smartercarter01]

Thanks for the suggestions! Just to save anyone else looking at this some time, I've already checked those specific angles.

Default branch: both workflow files are on master (confirmed via the Actions API, state: active).

Job-level if: conditions: neither workflow gates its job on anything. They run unconditionally once triggered.

Path filters: neither workflow uses paths:/paths-ignore: at all, and those only apply to push/pull_request triggers anyway, not schedule, I believe.

Concurrency: both workflows do use a concurrency: group (cancel-in-progress: false), but that wouldn't explain zero scheduled runs. I've seen clean, non-overlapping completions throughout, never a stuck/queued run blocking anything.

One update since I posted: the schedule trigger has actually started partially recovering on its own! Both workflows have picked up a handful of scheduled runs since I posted this (like, one every five hours), but nowhere near the configured hourly cadence, and with no code or config change on my end to explain it. That intermittent-recovery pattern feels like it might be a more useful data point for someone on GitHub's side than anything client-configurable, but I'm not opposed to suggestions.

If I need to share exact timestamps/run IDs to help someone dig into backend scheduler logs, I will.