Scheduled workflows never trigger in a private repository, while push and workflow_dispatch work

[TarifZen]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Schedule & Cron Jobs

Discussion Details

Hello,

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

Repository: https://github.com/TarifZen/tarifzen-scraper

The problem

Scheduled workflows (schedule) never start. However, workflows triggered manually (workflow_dispatch) or by a push event work correctly.

What I have checked so far

• The repository's default branch is main.
• GitHub Actions are enabled.
• Actions permissions are set to "Allow all actions and reusable workflows".
• The workflow files are correctly located in .github/workflows/.
• Manual executions using workflow_dispatch work successfully.
• Push-triggered workflows work successfully.
• I have tested several cron expressions, including */5 * * * * and 2-59/5 * * * *, without receiving any scheduled runs.
• The repository is private, and I am the only user with write access.

I also created a dedicated diagnostic workflow containing only a scheduled trigger and a few logging steps. It works when triggered manually or by a push, but no schedule event is ever generated.

My questions

1. Is there a way to check whether GitHub is actually generating scheduled events for this repository?
2. Could this be related to a repository-level or account-level issue?
3. Are there any additional settings or restrictions that could prevent scheduled workflows from triggering?

Any help or suggestions would be greatly appreciated.

Thank you!

[g4lb]

Run gh run list --event schedule --workflow NAME. An empty list shows that no scheduled run started.
If several off-hour cron values give no runs, contact Support (GitHub).

[nikoladimitrov98]

You're not alone. Many people have reported the same thing since around Oct 31: scheduled runs never arrive or are hours late, while push and workflow_dispatch runs work fine. See #212128 (5- and 15-minute crons firing only every 4–6 hours), #212160, #212101, #211723, #211816, #211839 and #211937. GitHub had Actions incidents on Nov 4 about "events that might trigger Actions". They're marked resolved, but the reports keep coming.

To your questions:

1. Can you check whether schedule events are generated? Not directly, because the scheduler has no public log. The only signal is whether runs appear: gh run list --event schedule --workflow .yml, or GET /repos/OWNER/REPO/actions/runs?event=schedule. Right now some repos only get a run every few hours, so check over a whole day, not a few minutes.
2. Repo or account problem? Very unlikely. The same symptom is showing up on many unrelated repos and accounts at the same time.
3. Settings that can block schedules: the workflow is disabled (check gh workflow list --all), the file isn't on the default branch, or the repo is a fork. GitHub also disables schedules after 60 days without activity, but only in public repos. From what you describe, none of these apply.

If the scraper needs to run on time, trigservice through workflow_dispatch:

curl -X POST \
  -H "Authorization: Bearer <TOKEN>" \
  -H "Accept: application/vnd.github+json" \
  https://api.github.com/repos/TarifZen/tarifzen-scraper/actions/workflows/<file>.yml/dispatches \
  -d '{"ref":"main"}'     

Use a fine-grained token limited to this repo, with Actions: Read and write permission. Keep the schedule: block too, and drop the external trigger once smal.

[TarifZen]

Update - November 6, 2026

After changing the cron frequency to once per hour, I have observed two successful scheduled runs:

• November 6 at 01:55 (Paris time)
• November 6 at approximately 08:52 (Paris time)

The hourly cron is configured to run at minute 00, so both executions were significantly delayed.

This suggests that scheduled events are now being generated, but with substantial delays.

I will continue monitoring the workflow over the next 24–48 hours to see whether the situation improves.

The issue does not appear to be completely resolved yet.

[alexisfarwati-hub]

Same issue here, also a private repository.

Repository: alexisfarwati-hub/trading-bot-reports (private)
Workflow: .github/workflows/heartbeat-watch.yml (id 410697341), state active

The workflow has on: schedule with cron 23,53 * * * * (earlier 7,37 * * * *). Since it was added to the default branch main on 2026-11-07 at 22:02 UTC, GitHub has started zero schedule runs. Three workflow_dispatch runs of the same file succeeded (22:02–22:04 UTC). Manual runs succeed; scheduled triggering remains unverified.

Already tried: disabling and re-enabling the workflow (23:57 UTC), and a new commit to the workflow file on main (e439a7e, 00:19 UTC). githubstatus.com showed no Actions incident.

Could GitHub staff check whether scheduled events are held or blocked for this repository or account, and re-enable them? This job is a safety monitor, so we rely on the schedule.

Has GitHub identified a fix or workaround for scheduled runs not being created?

[TarifZen]

In my case, scheduled runs do eventually happen, but they are extremely delayed and inconsistent.

For example, with an hourly cron ("0 * * * *"), I observed scheduled runs approximately 4 to 8 hours apart, instead of every hour.

I also have a second diagnostic workflow scheduled at 03:00 and 04:00 UTC. Its runs appeared several hours later than expected.

Both workflows execute successfully when triggered, and their logs confirm that the event type is "schedule".

This makes me think there may be a broader issue with GitHub's scheduled event processing, affecting private repositories differently.

Hopefully GitHub is investigating this.

[Fuma2514]

What's actually happening

Scheduled (cron) events are handled very differently from push/workflow_dispatch, which is exactly the asymmetry you're seeing:

• push and workflow_dispatch are delivered by the normal event pipeline: the payload is written synchronously when you push or click the button, so those runs fire essentially immediately.
• schedule events are produced by GitHub's shared cron dispatcher, which enqueues the event into the same global queue as everyone else's repos and then applies load shedding. There is no per-repo guarantee and no SLA — during high-load windows (recently common for */5-style frequent crons), events are delayed by minutes-to-hours or skipped entirely, with no record left in gh run list --event schedule (a skipped slot simply never creates a run). This matches the delayed/dropped pattern reported in the thread since ~Oct 31.

Also note two scheduler rules that interact with this:

1. Only the default branch schedules are considered; every other branch's schedule trigger is ignored.
2. A repository with no commit activity for 60 days has scheduled workflows auto-disabled (re-enable via push/workflow_dispatch). Your repo is active, so this doesn't apply, but it's worth ruling out.

What to do

• Diagnose with gh run list --workflow <name> --event schedule --created ">YYYY-MM-DD" — an empty list means the event was never delivered (not a failure of your workflow).
• Don't rely on cron alone for anything latency-sensitive. The robust pattern is a decoupled trigger: an external cron (GitHub App with a webhook, a cron job on any host, or GitHub's own REST API POST /repos/{owner}/{repo}/actions/workflows/{workflow_id}/dispatches) calling workflow_dispatch. workflow_dispatch goes through the synchronous path and is not subject to cron shedding.
• If you must stay on schedule, prefer one precise hourly cron over high-frequency */5 expressions; frequent crons get shed far more aggressively than hourly ones under load, which is consistent with your observation that a once-per-hour expression eventually ran.
• If delays persist across several days on an hourly cron, it's a platform-side incident; include run IDs and timestamps when opening a support ticket, since schedule delivery has no client-side debug surface.

Reference for the semantics: Events that trigger workflows – schedule (documents the default-branch rule, the 60-day disable, and the "high load can delay scheduled events" caveat).