GitHub Actions scheduled workflow runs only 5–6 times per day instead of hourly

[smilelezha-star]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

ARC (Actions Runner Controller)

Discussion Details

Hello GitHub Community,

I'm investigating irregular GitHub Actions scheduled workflow execution.

The workflow is active on the default branch and configured with:

cron: '27 * * * *' (UTC)

However, the GitHub Actions API shows the following schedule-triggered runs:

October 18, 2026: 6 runs
October 19, 2026: 5 runs
October 20, 2026: 5 runs
October 21, 2026: 5 runs

Most runs that actually start complete successfully.

We understand that GitHub Actions scheduled workflows may be delayed or dropped under high load. We are not claiming that every missing hourly run was definitively dropped.

Could someone help clarify:

1. Can we determine whether an expected schedule event was delayed, dropped, or never queued?
2. Can a workflow run be matched to its originally intended cron execution time?
3. What could cause this recurring pattern over several days?
4. Is there a diagnostic or escalation channel available for GitHub Free accounts?

We are looking for diagnostic guidance only, without rerunning workflows or changing repository settings.

Thank you!

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[luisfs4]

Short version: GitHub doesn't expose dropped schedule events. You can only see the runs that were actually created, so the rest has to be inferred by comparing them against the cron slots. Point by point:

1. Delayed vs. dropped vs. never queued. A dropped schedule event never creates a run, so there's nothing for it in the UI or the API. What you can measure is the runs that did get created and how late they were:

gh api -X GET --paginate \
  repos/OWNER/REPO/actions/workflows/WORKFLOW_FILE.yml/runs \
  -f event=schedule -f created='>=2026-10-18' -f per_page=100 \
  --jq '.workflow_runs[] | [.created_at, .run_started_at, .status, .conclusion] | @tsv'

With cron: '27 * * * *' the expected slots are HH:27Z. A run whose created_at lands some minutes after a slot is that slot, delayed (delay = created_at − slot). A slot with no run before the next one is an event that was dropped, i.e. never queued.

2. Matching a run to its intended time. There's no field with the intended timestamp. Inside the run, github.event.schedule tells you which cron expression triggered it (useful when a workflow has several schedule entries), but not the slot. With a single hourly cron, the nearest earlier slot is the match. If you want an exact trail from now on, an optional first step can log it:

- run: echo "cron='${{ github.event.schedule }}' created=$(date -u +%FT%TZ)" >> "$GITHUB_STEP_SUMMARY"

3. What could cause the pattern. From the docs: "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." Minute 27 already avoids the top-of-the-hour spike, so a steady 5–6 runs a day for several days points at events dropped under load, not at something in your workflow. Two other causes you can rule out: scheduled workflows only run from the default branch (yours is), and in public repositories they're disabled after 60 days without activity (you'd get zero runs, not five).

4. Escalation. For a GitHub Free account this forum is the main channel; you can also try a ticket at support.github.com. Either way, attach the expected-vs-created table from step 1, because that's the evidence they'll ask for.

If the job ever has to run reliably every hour, the usual fix is not to depend on schedule alone and trigger it from an external scheduler with workflow_dispatch (gh workflow run WORKFLOW_FILE.yml --ref main, or POST /repos/{owner}/{repo}/actions/workflows/{workflow_id}/dispatches).