Scheduled workflow runs not being created (most slots missing, others delayed 1-3+ hours); workflow_dispatch works

[HardikRoboMQ]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Schedule & Cron Jobs

Discussion Details

Summary

My scheduled workflow is registered and has fired a few times, but most scheduled slots produce no run at all. The few runs that do appear are delayed by roughly 35 minutes to 3+ hours. Manual workflow_dispatch runs work normally.

Setup

• Repo: private, not a fork, default branch main (only branch)
• Workflow file: .github/workflows/psi-monitor.yml (on main, unchanged)
• Workflow state: active
• Runner: ubuntu-latest
• Schedule:

on:
  workflow_dispatch:
  schedule:
    - cron: "7 9,12,15,18,21 * * *"
      timezone: "Asia/Kolkata"

Intended slots: 09:07, 12:07, 15:07, 18:07, 21:07 IST (03:37, 06:37, 09:37, 12:37, 15:37 UTC).

Earlier I used a UTC-only cron without timezone (e.g. "30 7 * * *") and saw the same behavior, so I don't think the timezone field is the cause.

Evidence

Output of GET /repos/<OWNER>/<REPO>/actions/workflows/psi-monitor.yml/runs?event=schedule&per_page=50:

run_number	created_at (UTC)	status	conclusion
8	2026-10-08T18:59:51Z	completed	success
7	2026-10-08T10:54:08Z	completed	success
6	2026-10-07T16:52:53Z	queued	null
3	2026-10-06T16:12:49Z	completed	success

• Across Oct 7 and Oct 8 there were 10 expected slots, but only 3 scheduled runs were created (6, 7, 8).
• The missing slots have no run objects at all, not even queued or skipped, and enough time has passed that they look dropped rather than delayed.
• Observed lag where runs did appear: about 35 min (3), 75 min (6), 77 min (7), and 3+ hours (8) after the nearest earlier slot.
• Run 6 has been stuck in queued for about 1.5 days.
• As of 10:13 IST on Oct 9, the 09:07 IST slot had produced no run.
• Manual runs via workflow_dispatch start and complete normally (about 1-2 min).

Already checked

• Workflow is on the default branch and Actions is enabled
• No disabled/inactivity banner
• No if: condition restricting events to workflow_dispatch
• Cron uses off-peak minutes (not :00/:15/:30/:45)
• Schedule syntax is valid, and runs do fire occasionally

Questions

1. Is there a known incident or issue with the schedule trigger service? Similar reports: Scheduled (cron) workflows stopped firing. No run is created at all since 2026-08-26. #206019, Scheduled Actions workflow creates no runs; manual and push triggers work #209434, Scheduled workflow triggers stopped firing on a private repo, but manual workflow_dispatch is operating as expected. #203353.
2. Is there anything on my side (repo or account) that could cause schedule events to be dropped?
3. Can the stuck queued run (6) be cleared?

Happy to share more details if helpful.

[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. ⭐

[aniketatgithub]

This matches documented behavior rather than a repo-side misconfiguration. GitHub's docs for the schedule event say it can be delayed during periods of high load, and if the load is high enough, some queued jobs may be dropped. There is no guarantee that every cron slot produces a run, and instant workflow_dispatch runs alongside lagging schedule runs is the usual signature of that.

Two things worth noting from your setup:

• The timezone key is supported for schedule, and your IST conversions look right, so this is not a timezone math problem.
• A run stuck in queued, like your run 6, can be cancelled from the run page in the Actions tab, or with gh run cancel <run-id>, so it does not sit there indefinitely.

If you need firmer timing than the schedule trigger offers, the common workaround is an external scheduler elsewhere that calls workflow_dispatch through the API. Within GitHub alone, off-peak minutes, which you already use, are the only mitigation GitHub documents.

[anis-mselmi]

There is no public endpoint that lets a repository owner force a schedule run or inspect a hidden schedule-registration queue. The useful checks are the ones you have already started: confirm the workflow is enabled, present on the default branch, and query workflow runs with event=schedule. GitHub documents that scheduled workflows can be delayed during high load and that some scheduled runs may be dropped; workflow_dispatch succeeding does not prove every cron slot will create a run. If reliable execution is required, use an external scheduler to call workflow_dispatch, or have the scheduler retry/report missed slots. For the queued run, cancel it from the Actions UI or with gh run cancel <run-id> if GitHub accepts the cancellation; a run that remains inconsistent needs GitHub-side investigation.

[slyyr]

The fact that workflow_dispatch succeeds while scheduled runs are missing is an important clue. It suggests that the workflow can execute manually, but it doesn't by itself establish why the scheduled events are missing.

I'd investigate these areas separately:

1. Confirm that the workflow file exists on the repository's default branch and that the workflow is enabled.
2. Check the actual scheduled times in UTC, accounting for the configured timezone.
3. Inspect the Actions run history for schedule events separately from manual dispatches.
4. Check whether the workflow was recently disabled, modified, or moved between branches.
5. Compare the missing time slots with the GitHub Actions status page and reports from other users.

For a diagnostic API query, filtering workflow runs by the schedule event can help distinguish scheduled executions from manually triggered runs.

I'd also keep a simple record of expected schedule times and observed run creation times. That makes it easier to demonstrate whether runs are consistently delayed or entirely absent.

Because the report includes multiple missing runs and substantial delays, I'd avoid assuming that a cron expression change will fix it without further evidence. If the configuration is valid and the problem persists across multiple time slots, the collected run IDs and timestamps would be useful evidence for GitHub to investigate.