Private repository: no schedule events, while workflow_dispatch and push work

[rubenpuiu-design]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Schedule & Cron Jobs

Discussion Details

I have an active private, non-fork repository on GitHub Free, with main as the default branch. This is a reduced trigger excerpt; job bodies and path filters are omitted:

on:
  workflow_dispatch:
  schedule:
    - cron: '47 * * * *'
  push:
    branches: [main]

Manual and push-triggered executions succeed on GitHub-hosted runners. The workflow's current menu offers Disable workflow, confirming it is enabled. The owner account is active and has write/admin access. Listing repository runs with event=schedule returns total_count:0.

An hourly schedule was first added on 26 October 2026 at 03:13 UTC, initially at minute 17. One controlled change to minute 47 was merged at 07:43 UTC. It preserved the hourly frequency, job bounds and permissions. No scheduled run was observed across multiple expected windows. We have not added another timer, increased frequency or repeatedly dispatched diagnostic runs.

GitHub Status reported Actions operational and no active incident when checked that day; this does not rule out a repository-specific issue. We understand schedules can be delayed/dropped and only run on the default branch. The 60-day public-repository inactivity rule does not apply here.

Which supported read-only checks can determine why scheduled run objects are not being created? Can an owner inspect schedule registration or a relevant account/repository restriction through a supported interface? We are not seeking an exact start-time guarantee.

Repository/account identifiers, commit SHAs, logs, source code, credentials and project details are intentionally omitted.

[AdisBacic]

Hey! Unfortunately there's no supported way to see whether a schedule is registered. When no run gets created, nothing gets logged anywhere you can see. So the best you can do is rule out the usual causes, and from what you describe, you already have.

Quick checks if you want to be thorough:

• gh api repos/OWNER/REPO/actions/workflows --jq '.workflows[] | {name, state}' should say active.
• Schedules are tied to whoever last changed the cron line. Check that the commit is linked to your account. If author comes back null here, the commit email isn't on your GitHub account:

  gh api "repos/OWNER/REPO/commits?path=.github/workflows/FILE.yml&per_page=1" --jq '.[0].author.login'

You're not alone, though. Since early October a bunch of people have reported exactly this: private repo, workflow active, push and manual runs fine, but no scheduled runs ever (#210175, #210326, #210337, #210401). Nobody found a config cause, so it looks like it's on GitHub's side.

What I'd do:

1. Try toggling the workflow off and on. It's a different way to re-register than editing the cron:

   gh workflow disable FILE.yml
   gh workflow enable FILE.yml

2. If the job matters, trigger it from somewhere else for now. Manual runs work for you, so any external cron (a Cloudflare Worker, a server, a scheduled workflow in another repo) can just call:

   gh workflow run FILE.yml --repo OWNER/REPO --ref main

   A fine-grained token for just that repo with Actions: Read and write is enough. Leave the schedule: block in, so you'll notice when it starts working again.

If you want GitHub to look at it, a Support ticket with your event=schedule → total_count: 0 result and the times you changed the cron is the way to go.

[zaid617]

I've noticed similar reports recently, including [#209378](https://github.com/orgs/community/discussions/209378) and [#210193](https://github.com/orgs/community/discussions/210193), where manual runs work but scheduled runs are missing entirely.

The detail that stands out here is event=schedule returning total_count: 0. That suggests the problem is happening before a workflow run reaches a runner, rather than inside the job itself.

Disabling and re-enabling the workflow is worth trying once, but if the schedule still produces no run after several expected windows, repeatedly changing the cron expression probably won't tell you much more. As far as I know, repository owners don't have a public interface for inspecting the scheduler's registration state.

It would be helpful for GitHub to confirm whether these reports share a common cause. Until then, I'd avoid treating this as a confirmed configuration issue, especially since the usual checks have already been covered here.