GitHub Actions schedule never triggers, but manual runs succeed

[Lukass-tech]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Schedule & Cron Jobs

Discussion Details

Hello, scheduled runs are never created for my GitHub Actions workflow, although manual runs succeed.

This is a private repository on GitHub Free. The workflow file is .github/workflows/paper-read.yml on the default branch, main.

The trigger configuration is:

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

The job uses ubuntu-latest, actions/checkout@v6 and actions/setup-node@v6 with Node.js 24. It runs npm test and a read-only API integration check. Manual runs complete successfully in 15–23 seconds.

On November 12, 2026, no scheduled runs appeared after several hours. There are no failed or queued scheduled runs—only manual runs and an initial YAML validation failure that was subsequently fixed.

I have checked or tried:

• The workflow is saved on the default branch, main.
• Changing the cron from '17 * * * *' to '27 * * * *'.
• Disabling and re-enabling the workflow.
• Manually running the updated workflow successfully.
• Checking GitHub Status, which reported Actions operational.

The Actions paid-usage budget is $0, but manual runs still succeed.

What else can I check to determine why schedule events are not creating runs?

[Zabeeh-Ullah-Dev]

Since manual runs work, your workflow file and runners are fine. The problem is the schedule event is never being created, so the checks should focus on that side.

The most useful next step is to check whether GitHub created any schedule events at all. You can do that with the API:

curl -H "Authorization: Bearer TOKEN" -H "Accept: application/vnd.github+json" "https://api.github.com/repos/OWNER/REPO/actions/workflows/paper-read.yml/runs?event=schedule"

If that returns nothing, the scheduler never fired, which points at GitHub rather than your config. If it does return runs, then the runs exist but something is off with how they show up in the Actions tab, which would be a different problem.

Two things that commonly cause this:

1. GitHub automatically disables scheduled workflows when a repository has had no activity for 60 days. You already disabled and re-enabled the workflow, but also push a fresh commit to main if the repo has been quiet. That makes sure the schedule is picked up again.

2. Scheduled runs are best effort, not exact. They can be delayed when the platform is under load, and a few people have reported schedule events not being generated at all this week. Your status check already rules out a posted incident, but it is still worth rechecking the status page before you spend more time on config.

Your cron is fine. '27 * * * *' is valid and hourly is well above the 5 minute minimum interval, and schedules run in UTC, so the timing is not the issue.

Try the API call first. If it shows no schedule events, the config is not the problem and it is worth contacting GitHub Support, since the community cannot inspect the scheduler for your repo.

[Lukass-tech]

Thanks, I checked the API using a manually triggered diagnostic workflow.

The workflow endpoint returned:
{"name":"Kontrola paper uctu","path":".github/workflows/paper-read.yml","state":"active"}

The runs endpoint filtered by event=schedule returned:
{"runs":[],"total_count":0}

Both API requests succeeded. This confirms that the workflow is active and no scheduled runs are recorded.

The repository is newly created and has had several commits today, so 60 days of inactivity does not apply. Changing the cron and disabling/re-enabling the workflow did not help.

Is there another account-level or repository-level check available, or a way for GitHub staff to investigate the scheduler registration for a private repository on GitHub Free?

[Zabeeh-Ullah-Dev]

Your reading is right. state: active plus total_count: 0 means the scheduler has never created a run for this workflow, and the 60 day rule is out since the repo is new with commits today. So it is not your config.

One check is still worth doing. state: active only says the workflow is enabled, it does not prove the schedule trigger is in the file on main. Open .github/workflows/paper-read.yml on the main branch in the browser and confirm the schedule: block with the cron is actually there. If the main copy lost it during an edit, the scheduler has nothing to register.

If the file on main is correct, there is no other check you can run yourself. The scheduler registration is internal to GitHub, so the next step is a Support ticket at support.github.com, with these two API results, the repo and workflow name, and the fact that manual runs work. That is the route to get the Actions team to look at the scheduler side.

Until it is fixed, workflow_dispatch is your stopgap, just keep triggering it manually.

[Srikanthkesani2]

Check whether the repository has been inactive for 60 days, as GitHub automatically disables scheduled workflows in inactive public repositories. Also verify the cron syntax and ensure the workflow is enabled on the default branch.

[Lukass-tech]

Thanks. I have already verified all three points:

The repository is private, newly created, and has had several commits today.

The cron expression is valid: '27 * * * *'.

The workflow is on the default branch, main, and the API confirms its state is "active".

Manual runs succeed. However, the workflow runs API filtered by event=schedule returns:
{"runs":[],"total_count":0}

Changing the cron and disabling/re-enabling the workflow did not help. Are there any further checks for why scheduled runs are not being created?

[aungzayyanaing]

Your API check is the decisive evidence, and it already rules out the usual causes.

What the evidence proves

• state: "active" plus event=schedule returning {"total_count": 0} means GitHub never created a scheduled run for this workflow — this is not a runner, queue, or job failure. A queued or failed run would appear in that list.
• Manual runs succeeding proves the YAML, the checkout/setup-node steps, runner availability, and permissions are all fine.
• The 60-day rule does not apply: the repository is newly created with commits today, and GitHub only disables scheduled workflows after 60 days without repository activity.
• '27 * * * *' is valid, hourly is well above the 5-minute minimum interval, and scheduled times are in UTC, so the expected runs are at minute 27 of each hour UTC.

One last check worth doing

state: "active" only says the workflow is enabled. It does not prove the schedule: block is in the copy on main. Open .github/workflows/paper-read.yml on the main branch in the browser (or fetch it through the contents API) and confirm the committed file actually contains:

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

If that block is missing from main, the scheduler has nothing to fire — fix the file on main and wait for the next hour. If it is there, you have exhausted the checks you can run yourself: changing the cron and disabling/re-enabling the workflow are the only user-side resets for schedule registration, and you already tried both.

What to do next

In that case this is a platform-side scheduler issue, not a configuration problem. Open a ticket with GitHub Support and include the repository and workflow path, the state: "active" result, the event=schedule result with total_count: 0, and the UTC times at which hourly runs were expected but never appeared. Until it is resolved, workflow_dispatch — manually, or with gh workflow run / the workflow-dispatch API — is the reliable stopgap.

Scheduled runs are best-effort and can be delayed under load, but zero hourly runs over several hours is not a normal delay when the workflow is active on the default branch.