Hourly scheduled workflow runs only every 3–9 hours: how to investigate gaps?

[5colors2015]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Schedule & Cron Jobs

Discussion Details

I am investigating an hourly scheduled workflow in a private repository.

Configuration:

• Cron: 23 * * * * (UTC).
• The workflow is active and its definition is on the default branch.
• Workflow concurrency is configured with cancel-in-progress: false.

Observations over several days:

• Scheduled runs appear at roughly 3–9-hour intervals rather than hourly.
• The recorded runs complete successfully and take only about 10–25 seconds.
• Run creation and recorded run-start timestamps are nearly simultaneous. We have not observed long queue waits that explain the multi-hour gaps.
• The visible gap is therefore before run creation in the available run history, rather than a long-running or failing job. This does not establish whether individual schedule events were delayed, skipped, or suppressed internally.

I understand that scheduled workflows can be delayed under load and are not guaranteed to run at an exact time. I have searched for similar discussions and found related reports, but I do not know whether they share the same cause.

What evidence or checks can distinguish ordinary scheduling delay from persistent multi-hour gaps before run creation? Is there a way to inspect the disposition of individual scheduled events, or an appropriate channel for asking GitHub to investigate this pattern?

I am not claiming a confirmed platform incident. Repository identifiers and execution identifiers are intentionally omitted from this public question.

[weuderr]

What you're seeing matches documented behavior. Even so, you can collect evidence and get it investigated.

Why it happens: the schedule trigger is best-effort. GitHub's docs say: "The schedule event can be delayed during periods of high loads of GitHub Actions workflow runs. … If the load is sufficiently high enough, some queued jobs may be dropped." Dropped schedule events leave no trace in the run history. No skipped or cancelled run is created, which is why you only see gaps "before run creation". :23 is a good choice (off the top of the hour), but it doesn't guarantee delivery.

How to measure it:

gh run list --workflow <file>.yml --event schedule --limit 200 \
  --json createdAt,databaseId,status \
  --jq '.[] | [.createdAt, .databaseId, .status] | @tsv'

Comparing createdAt against the expected HH:23 slots gives you two numbers: the fraction of slots that got a run at all, and the delay of the ones that ran. Delays of minutes up to ~1h are "normal load". A run every 3–9 hours means most events are being dropped, not delayed.

Things worth ruling out on your side (each can silently suppress schedules):

• The cron is read from the default branch at trigger time. If the workflow file was renamed or moved recently, re-save it. A trivial commit touching the file re-registers the schedule.
• concurrency with cancel-in-progress: false doesn't drop runs, but a pending run in the same group does replace the previous pending one. With 10–25s runs that's unlikely, but check that no other workflow shares the same concurrency group name.

Who can see the disposition of individual events: only GitHub. Open a ticket at https://support.github.com (Actions). Include the repo, the workflow file and your createdAt table privately. Support can look up whether events were dropped or throttled, which this public forum can't.

If you need reliable hourly execution: trigger it externally and keep schedule only as a fallback. For example, a cron on any server, Cloud Scheduler, or a cron-job.org job calling:

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

with on: workflow_dispatch in the workflow. Those runs are created immediately and aren't subject to schedule dropping.

[5colors2015]

Thanks for the helpful explanation and suggestions. I’ll review the run timestamps and consider the options you outlined. I appreciate your help!

[its-jani]

Here is a response you can copy and paste into the comment box. It builds on the existing thread but gives a highly practical, developer-to-developer solution to completely bypass the issue:

Hey there! Dealing with this is super frustrating. Just to add a bit of practical context to what's already been mentioned—because GitHub's scheduling is strictly "best effort," when their internal queues get slammed, they don't just delay your scheduled runs; they silently drop them entirely. That's exactly why you aren't seeing any queue times or failed runs in your logs. It's as if the event never fired.

Since you're already using an off-hour minute (:23) and still seeing 3-to-9-hour gaps, you've likely hit the limit of what native Actions cron can reliably do for your specific repository load right now.

If you absolutely need this to run every single hour without fail, the best move is to take the scheduling responsibility away from GitHub entirely.

The Bulletproof Fix:
Set up an external scheduler (like AWS EventBridge, Google Cloud Scheduler, or even a free service like cron-job.org) to ping the GitHub API every hour and trigger a workflow_dispatch event. workflow_dispatch events get much higher priority in GitHub's queue than schedule events, meaning they almost never drop.

Here’s how to set it up quickly:

Add workflow_dispatch: to your on: triggers in the workflow .yml file.

Generate a Fine-grained Personal Access Token (PAT) with Actions: Read and Write permissions for that repo.

Have your external cron fire this exact cURL payload every hour:

Bash
curl -L
-X POST
-H "Accept: application/vnd.github+json"
-H "Authorization: Bearer YOUR_TOKEN_HERE"
-H "X-GitHub-Api-Version: 2022-11-28"
https://api.github.com/repos/OWNER/REPO/actions/workflows/YOUR_WORKFLOW_FILE.yml/dispatches
-d '{"ref":"main"}'

This entirely bypasses the silent dropping issue and guarantees your job gets queued hourly. Hope this helps get your workflow stabilized!

[5colors2015]

Thanks for the specific suggestions. I’ll review the permissions and reliability as I evaluate this approach. I appreciate your help!

[shivanagendrakore]

Short answer: there is no per-event disposition log you can inspect — GitHub does not expose whether an individual schedule firing was delayed, queued, or dropped. What you can do is build the expected-vs-created timeline and rule out the repo-side causes, after which the remaining explanation is platform delay/drop, which the docs explicitly allow for:

"The schedule event can be delayed during periods of high loads of GitHub Actions workflow runs. High load times include the start of every hour. If the load is sufficiently high enough, some queued jobs may be dropped." — Events that trigger workflows: schedule

How to distinguish the cases with evidence:

1. Expected vs created, exported. List only schedule-event runs with creation times, e.g. gh run list --event schedule --created "<range>" --json createdAt,event,status,conclusion,workflowName (or the REST equivalent) and diff against the hourly :23 slots. Runs that appear hours late with createdAt ≈ start time = delayed-then-created. Slots with no run at all = dropped/suppressed. Your observation (creation ≈ start, short runs) already rules out queue wait and long jobs.
2. Repo-side suppressors to eliminate. Schedule only fires from the default branch (already confirmed), the workflow must not be disabled (Actions tab → workflow → ···), and in public forks schedules auto-disable after 60 days without activity. Also confirm no one edited the cron or default branch mid-window (git log on the workflow file), since GitHub registers schedule changes with a lag.
3. Your minute choice is already right. :23 avoids the top-of-hour load spike the docs call out, so moving the minute is unlikely to explain 3–9 hour gaps.

If exact hourly execution matters, treat schedule as best-effort and drive the same workflow from outside: an external cron (EventBridge, cron-job.org, etc.) calling POST /repos/{owner}/{repo}/actions/workflows/{workflow_id}/dispatches (workflow_dispatch) gives you a scheduler whose firings you can log. Keep the schedule trigger as a fallback if you like.

And yes, there is a channel for the platform pattern itself: GitHub Support can check service-side scheduling for the repo if you give them the repo, workflow, and a few expected-vs-missing timestamps (fine to share privately there, unlike here). If you post the exported expected-vs-created table (repo redacted), folks here can sanity-check the classification before you file it.

[5colors2015]

Thanks for the helpful suggestions. The timeline comparison and configuration checks are useful for narrowing this down. I appreciate your help!