GitHub Actions scheduled workflows can silently skip runs, and the fix may be an external scheduler

Scheduled runs that never happened

A write-up on dev.to documents a GitHub Community discussion (thread #207247) in which a user reported that an hourly GitHub Actions workflow simply stopped producing runs. The workflow used the cron expression 17 * * * *, yet several consecutive expected executions never materialised — and there was no trace of a run at all. Nothing failed, nothing queued, nothing was cancelled: the scheduled event was never created.

According to the dev.to article, the original poster, jessie-mele, could still trigger the workflow manually via workflow_dispatch, and those runs completed successfully. That ruled out problems in the workflow's logic, jobs, or runner assignment, and pointed instead at the event trigger itself. The user had already shifted the schedule away from the top of the hour — from 0 * * * * to minute 17 — to dodge peak load, but the skips continued, and the runs that did fire were sometimes badly delayed.

A best-effort scheduler

Respondents in the thread, including TongyiDai and Dotoryman, agreed the fault lay upstream with GitHub's scheduler. GitHub's documentation, cited in the discussion, describes scheduled events as "best-effort": under sufficient load they may be delayed or dropped, with congestion clustering around the start of each hour, when large numbers of cron jobs fire at once.

An occasional late run is normal drift. Five consecutive missing hourly triggers, as the dev.to piece notes, looks like something more structural — a failure to emit the schedule event at all rather than a problem executing it.

How to diagnose a silent schedule

The community's first line of defence is a set of checks intended to force the workflow back onto GitHub's scheduler:

• Inspect the workflow and repository state with the GitHub CLI — confirm the workflow is active, the default branch is correct, and no archived or disabled flags are set.
• List recent runs filtered by the schedule event, to verify that no run objects exist for the missing windows.
• Cycle the workflow off and back on with disable and enable commands, which can nudge GitHub into re-registering it.
• Make a genuine change to the cron expression on the default branch — for instance moving from minute 17 to minute 23 — which often prompts GitHub to re-evaluate and re-register the schedule. The thread advises against leaning on repeated empty commits as a workaround.

Escalating to GitHub Support

If scheduled runs remain absent after all that, the dev.to article is blunt: this cannot be fixed with further repository-side configuration, and the next step is a support ticket. There is a catch, though. Your repository keeps no log of an event the scheduler never emitted, so GitHub's investigators depend entirely on the evidence you supply. The recommended ticket contents include the workflow ID and repository URL, the exact UTC windows where runs were expected but never created, the timestamp of the last successful scheduled run, a link to a recent successful workflow_dispatch run as proof the workflow itself is healthy, an explicit statement that the missing slots have no run or job records whatsoever, and timestamps of any disable/enable cycles or cron edits performed.

Designing around the limitation

The broader lesson the article draws is architectural. For hourly jobs with hard delivery requirements, it recommends placing an external scheduler in front of the workflow — a dedicated cron service, AWS EventBridge, or Azure Logic Apps are the examples given — and having it invoke workflow_dispatch. The delivery guarantee then sits with a system you control and can monitor independently, while the workflow logic stays inside Actions.

Why it matters

Scheduled workflows quietly carry a lot of operational weight: dependency updates, nightly test suites, backups, and release automation all assume the trigger will fire. When a scheduler drops events silently, nothing fails loudly — the pipeline simply does not run, and the first symptom may surface days later as stale dependencies or a missed window. Knowing that GitHub's native scheduling is explicitly best-effort should shape which tasks teams entrust to it. The community thread offers both a practical runbook for when it misbehaves and a clear pattern — external scheduler plus workflow_dispatch — for pipelines that cannot afford a single missed run.