Schedule never creates runs in a new private repo, but workflow_dispatch works

[AlessiaInitiative]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Schedule & Cron Jobs

Discussion Details

Two workflows on main (the only and default branch) of a private repository I created on 2026-11-08 have never produced a scheduled run. Manual workflow_dispatch runs of the same files start and succeed.

• The hourly workflow has had a schedule on main since 16:46 UTC. It used 17 * * * *, then 23 * * * *, then */5 * * * * from 21:42 to 22:04 UTC.
• At 22:18 UTC, I added the minimal workflow below as a new file to check whether a fresh workflow would register.
• A later push at 23:22 UTC, with no workflow changes, made no difference.
• gh workflow list shows both workflows as active, and Actions is enabled for the repository.

After multiple expected trigger times, gh run list --event schedule still returns no scheduled runs for either workflow. The Actions UI shows only manual runs. There are no failed, queued, or skipped scheduled runs—no scheduled run records exist.

name: Schedule probe
on:
  workflow_dispatch:
  schedule:
    - cron: '*/5 * * * *'
permissions: {}
jobs:
  heartbeat:
    runs-on: ubuntu-24.04
    timeout-minutes: 2
    steps:
      - name: Record trigger
        run: |
          echo "event=${{ github.event_name }}"
          date -u +'%Y-%m-%dT%H:%M:%SZ'

Is there a repository, account, or plan condition that prevents schedule events from creating runs, or a known registration delay for new private repositories? I’ve omitted the repository name because it is private. If GitHub staff need it, I can provide it through a private Support ticket.

[XY-code1]

Since both workflows are enabled on the default branch and manual runs succeed, I would focus on whether the schedule event is being delivered, not on runner selection or the heartbeat script. As a control, leave the existing off-hour cron unchanged and run the same probe in a known-working private repo under the same owner, ideally with the same user making the cron commit. Compare the expected UTC slots against the actual schedule run records in both repos. If the control fires repeatedly and the new repo still has zero records, send those UTC slots, the workflow commit SHA, and a successful manual run ID to Support privately. That is evidence of a repo-specific difference, not proof of a registration delay.

GitHub documents scheduler delays under load and an inactive schedule actor as separate causes: https://docs.github.com/en/actions/how-tos/troubleshoot-workflows#scheduled-workflow-stopped-running

[AlessiaInitiative]

Thanks for suggesting a same-owner control. I found an existing scheduled workflow in another private repository in my account, so I didn’t create a new probe. Its cron has been 23 13 * * 1 on the default branch since September 25. Its scheduled runs on October 5, 12, 19, 26, and November 2 were created between 19:22 and 22:22 UTC on those Mondays—roughly 6–9 hours after the expected 13:23 UTC slot.

The new repository has now produced two successful scheduled runs with its hourly 23 * * * * cron, at 2026-11-09 01:46:53 UTC and 09:55:55 UTC, with no scheduled run records between them. So the issue is no longer “zero runs,” but late and intermittent runs in the new repo, plus substantial lateness in the older one. Does this control change what you would investigate next? Is there a supported way to see which nominal cron slot produced a delayed run?

[MrFabry]

Probably nothing wrong with your repo. There's been a wave of exactly this since around Oct 31, mostly private repos: scheduled runs either never show up or arrive hours late, while push and workflow_dispatch work fine. See #212156 and #212128 (5 and 15 minute crons firing every 4 to 6 hours). In #212156 someone else added a scheduled workflow to main on Nov 7 and got zero scheduled runs too, and disabling/re-enabling it and pushing a new commit to the file didn't change anything, so I wouldn't spend more time on that.

The one thing that moved at all there: TarifZen switched to an hourly cron and did start getting scheduled runs, just 4 to 8 hours apart. So I'd stop editing the cron and leave one hourly expression at an odd minute running for a full day before drawing conclusions.

If you need it to run on time right now, trigger it from outside with workflow_dispatch, since that path works for you. Any external cron (cron-job.org, a scheduled Cloudflare Worker, a server you already have) can call:

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

Use a fine-grained token limited to that one repo with Actions: Read and write. Keep the schedule block in the workflow too, so you can drop the external trigger once schedules come back.

I'd also add your case to #212156 with the UTC slots you listed. Same pattern, and that's where the reports are piling up.

[AlessiaInitiative]

Thanks for the related reports and the external-dispatch suggestion. I’ll leave my hourly 23 * * * * cron unchanged for a full day as you recommend. So far it has produced two successful scheduled runs, at 2026-11-09 01:46:53 UTC and 09:55:55 UTC—an 8-hour-9-minute gap with no intervening scheduled run records.

I also checked an older private repository in my account: its weekly 23 13 * * 1 workflow has produced scheduled runs, but the five October–November runs started roughly 6–9 hours after their expected UTC slot. That seems consistent with the delays you described in #212156 and #212128. Have you seen whether those reports distinguish runs delayed for hours from cron slots that are dropped entirely? I’ll follow #212156; if timely monitoring becomes necessary, I’ll evaluate an external workflow_dispatch trigger.

[MrFabry]

From what's in those threads it looks mostly dropped, not just late. In #212128 the 5 and 15 minute crons got one run every 4 to 6 hours, and in #212156 the hourly one got runs 4 to 8 hours apart. If slots were only being delayed you'd still end up with one run per slot, or a burst of catch-up runs after a gap, and nobody in the ones I read saw that. Your hourly cron with two runs 8 hours apart and nothing in between looks the same.

Your weekly one fits too I think. It only has one slot in that window so there's nothing in between to lose, it just shows up 6 to 9 hours late. My guess is the scheduler is only getting around to each workflow every few hours right now and fires what's due at that point, but that's just reading the pattern from outside, GitHub hasn't said anything about how it works.

The docs do say that under enough load some queued scheduled jobs can be dropped, and a dropped slot leaves no run record at all. So the only way to count them is comparing the slots you expected against something like gh run list --workflow <file> --event schedule --json createdAt --limit 100 over a day.

[AlessiaInitiative]

Thanks—comparing expected slots with run records makes the gap clearer. Our hourly :23 workflow has had 22 nominal slots since the cron was restored, but only two scheduled run records (01:46:53 and 09:55:55 UTC on Nov 9), with no catch-up burst so far. Manual runs work. I agree dropped events look plausible, though the run records don’t reveal GitHub’s internal cause.

[MrFabry]

Yeah, from the outside the run records are all we get. 22 slots and 2 runs is a really clear number though, I'd post exactly that in #212156. The more reports with real counts there, the more likely someone at GitHub picks it up. And if you need it on time before it's fixed, the external dispatch will do it.