Hourly cron produces successful runs roughly 4–8 hours apart: what to check?

[jennyuan0309-droid]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Schedule & Cron Jobs

Discussion Details

My GitHub Actions workflow has this hourly schedule:

on:
  schedule:
    - cron: '17 * * * *'

The scheduled runs I observe are roughly 4–8 hours apart. They eventually complete successfully, but the observed frequency is much lower than hourly. Manual runs work normally.

I have not established the cause and am not assuming this proves a platform fault or that every missing hourly run was dropped.

Are there any known scheduling limits or delays that could explain this pattern? What safe, read-only checks would help distinguish scheduling delay or dropped events from a configuration or repository-level restriction?

I would appreciate guidance that does not require exposing repository details or triggering additional runs.

[Manishram-ai]

4 to 8 hours between runs is way more than the usual schedule lag, so I'd start by finding out whether the missing hours never got a run at all or got one that was thrown away. Listing only the schedule runs shows that quickly, and it doesn't change anything.

gh run list --workflow your-workflow.yml --event schedule --limit 50 --json createdAt,status,conclusion

If there's a run for most hours but the ones in between are cancelled, look for a concurrency group in the workflow. Only one run can wait while another is in progress, and a newly queued run cancels the one that's already pending (docs). If your job takes a few hours, that gives you exactly this pattern. skipped runs usually mean a job-level if: that came out false.

If there's a run every hour but each one started late, compare the run's createdAt with when its jobs actually started.

gh run view <run-id> --json createdAt,jobs --jq '{createdAt, jobs: [.jobs[] | {name, startedAt}]}'

A big gap there means the job sat waiting for a runner, which happens a lot with a self-hosted runner that's offline or busy.

If there's simply no run in the gaps, the schedule events weren't created, and that part is on GitHub's side. Their docs say schedule events can be delayed under high load and some can be dropped (schedule notes). Your :17 minute isn't the problem. For comparison, electron/electron has a workflow on the exact same 17 * * * *, and over the last four days it got a run about every hour, 4 to 29 minutes late. A few people have posted multi-hour delays this week too, like #211921, so if your list shows real gaps, the run times are what GitHub Support would need to look into it. If it really has to run every hour, an external cron that calls the workflow_dispatch API is more dependable than schedule.

[Muguett-DBY]

One more read-only check before attributing the missing hours to GitHub:

gh api 'repos/OWNER/REPO/actions/workflows/WORKFLOW.yml' --jq '{path,state}'

That shows the workflow's current state, not its state during an earlier gap. It is also worth checking the workflow file's history on the default branch, and whether the default branch changed during the period. Scheduled workflows only run from the default branch; in a public repository, they can also be disabled after 60 days without repository activity.

An absent run alone doesn't tell you whether GitHub delayed or dropped work, or whether the workflow was ineligible at the time. The inactivity rule wouldn't explain repeated 4–8 hour gaps if the workflow stayed active. These checks don't require sharing repository details or starting a run.