No scheduled runs created in a private Free repository: which read-only diagnostics distinguish trigger rejection from delay?

[MrJuanCarlos]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Schedule & Cron Jobs

Discussion Details

I am investigating a scheduled GitHub Actions workflow in a private, personally owned repository on GitHub Free. I would appreciate a supported diagnostic route before scheduling another bounded test. Repository identities, source and application details are intentionally omitted.

What was verified during the test:

• The workflow file was on the default branch, main, and the workflow API reported state=active before the expected UTC slots.
• Repository Actions permissions reported enabled=true, allowed_actions=all and sha_pinning_required=false.
• The schedule used off-the-hour times. An hourly slot and later dated slots produced no visible runs, including after tens of minutes of observation.
• The dated preflight job used ubuntu-latest and only printed a marker. It needed no checkout, third-party action, secrets or external HTTP. Its job condition selected the matching schedule event; other jobs were deliberately gated off.
• Both the Actions UI and successful workflow-runs API reads showed zero runs, not a queued run. No workflow-validation check-run error was visible on the commit; I recognise that this does not prove acceptance by the scheduler.
• The included Actions allowance was not exhausted. No paid usage was enabled.
• Re-enabling the workflow and a new commit adjusting the cron expression did not produce an observed scheduled run in the bounded test. It is now deliberately disabled.

Important limitation: one manual workflow_dispatch diagnostic request returned a CLI operation error, but its original HTTP response detail was not retained. No run appeared afterwards. I cannot claim that manual dispatch works, identify its error code, or use it to isolate this as a scheduler-only fault. I have not repeated that request.

I have read the documented default-branch requirements and possible schedule delays/dropped events:
https://docs.github.com/en/actions/how-tos/troubleshoot-workflows

I also found the similar symptom in https://github.com/orgs/community/discussions/210399, but that report says manual runs work; that is not established in my case.

Which read-only checks or supported status/error surfaces can distinguish an event that was never accepted, an account/repository restriction, workflow validation failure and a delayed/dropped schedule when there is no run ID or log? If these cannot be distinguished from the repository side, what is the appropriate diagnostic route for a Free personal account without publishing private repository details or enabling paid usage?

I am not asking for a guaranteed cron delivery time or treating the symptom as proof of a platform-wide incident. Thank you.

[BenkhiraAhmedBaderEddine1]

No user-visible surface records that a schedule event was generated or accepted. Schedule events don’t fire repo webhooks, they don’t appear in the Events API, and personal accounts have no audit log that records them. If no run object exists, no run ID, log or check-run exists either. So “never accepted” and “dropped/delayed” can’t be told apart directly. You can only eliminate the other causes.

Read-only checks that eliminate the other causes

Workflow validation. Open the workflow file in the web UI (blob/main/.github/workflows/.yml). A parse or validation error shows as a banner with a line number. Also check the Actions sidebar and GET /repos/{owner}/{repo}/actions/workflows/{id}: if the file failed to parse, name falls back to the file path instead of your name: value. Running actionlint locally is a good extra check. Note that a validation error on a schedule-only workflow produces no “workflow file issue” run, because that failed-run record is created for push-triggered workflows.
Which account the schedule runs as. Scheduled runs are attributed to the user who last modified the cron expression. If that account is flagged, restricted or has an unresolved billing or abuse state, the schedule can go silent. Check Settings → Billing and plans (Actions minutes and any account banners), your notification email, and the Actions tab for any restriction banner.
Rule out the known documented causes. The repo is not a fork (forks have schedules disabled by default), the file is on the default branch and the cron uses UTC. The 60-day auto-disable applies only to public repos, so it shouldn’t apply to a private one.
Platform status. Check githubstatus.com history for Actions incidents covering your test windows. It can’t prove the absence of a localized problem, but it rules out a declared incident.
Run listing with filters. GET /repos/{owner}/{repo}/actions/runs?event=schedule&created=>= (or the Actions tab’s Event filter) covers cases where the default view hides something. Zero results here matches what you already saw.

The most valuable isolation test: push or dispatch in the same repo

Add a trivial on: push workflow with the same marker job. If it runs, then Actions enablement, runner provisioning, minutes and account state are all healthy, and the fault is confined to the scheduler path. If it doesn’t run either, the problem is account or repo level, and the cron is a red herring.

A second test needs no private details at all: a throwaway public repo with the same minimal schedule workflow. If that fires and the private repo doesn’t, the problem is specific to the private repo or its configuration. If neither fires, it points at the account, or at the scheduler for new schedules. Public repos use no paid minutes.

The manual dispatch error

It is the single most informative clue you can still recover, and one repeat is low-risk. Run it with GH_DEBUG=api gh workflow run --ref main, or use gh api -i / curl -i, and save the status code, the response body and the x-github-request-id header. Typical causes are a 422 (no workflow_dispatch trigger on that ref), a 403 (permissions or token scope) or a 404 (wrong workflow identifier). If the failure was a CLI-side error rather than an HTTP error, that also tells you something, and the request ID is what GitHub staff need to trace a request.

Diagnostic route if it still can’t be distinguished

This can’t be resolved from the repo side. The supported route is the GitHub Support contact form (support.github.com/contact), which Free accounts can use, under the Actions category. That lets you share identifiers privately instead of in public. Include:

the workflow ID, the repo ID or node ID, and the account name
the UTC times of the expected slots and of the observation windows
the x-github-request-id from the dispatch attempt
the results of the push/public-repo tests above
a statement that the minimal job uses no secrets or external access

Posting only the non-identifying results (as you’ve done here) in the Community thread is still useful for pattern-matching with similar reports, but it can’t replace the ticket.

One caveat: even with everything healthy, GitHub documents that scheduled events can be delayed or dropped under load, and that is not distinguishable from a never-accepted event after the fact. Repeated absence across several different slots, with the push test passing, is the strongest evidence you can bring to Support.

[MrJuanCarlos]

Thank you. I have now recovered a precise result from a single authorised manual diagnostic. On 16 October 2026 at 03:05:08 UTC, workflow_dispatch returned HTTP 200 and a run ID. At 12:29:56 UTC that run was still queued, conclusion null, attempt 1, with zero jobs. Cancel and force-cancel each returned HTTP 409; the cancel response said "Cannot cancel a workflow run that has not been queued yet." The workflow remains deliberately disabled and there are no application secrets installed for this diagnostic. I have not repeated dispatch.

Important qualification: both jobs are intentionally conditioned on specific schedule events, so neither should execute on workflow_dispatch. The accepted dispatch therefore does not show that a manual job, runner or scheduler is working. Earlier native schedule slots produced no observed runs. I am not treating this as proof of an account restriction or a platform-wide incident.

Is the long-lived queued/no-job state expected when every job condition is false, and is there a supported read-only way to distinguish that state from an account/repository restriction? What is the safe supported route to resolve it before another bounded test? I have retained the request IDs privately. The official Free support policy covers account, security and abuse issues, so I do not assume that a private Actions technical-support ticket is included. No repository identity, private code or credentials are published here.

[BenkhiraAhmedBaderEddine1]

understood , thanks for this info's

[slyyr]

I'd separate the problem into two stages: whether GitHub creates the scheduled workflow run, and whether a created run waits in the runner queue.

Check the workflow's registered state using:

gh api repos/OWNER/REPO/actions/workflows \
  --jq '.workflows[] | {name, path, state}'

Also verify that the workflow file exists on the default branch and that the cron expression is valid.

Next, inspect the workflow run history and compare the expected UTC schedule with the actual run-creation and start times.

If no run is created, investigate the schedule configuration and workflow registration. If a run exists but starts late, investigate queueing and runner availability instead.

Scheduled workflows can be delayed, so the cron expression alone doesn't guarantee execution at an exact minute.

If this solves your issue, please mark this reply as the answer so other developers facing the same scheduling problem can find the solution!