GitHub Actions scheduled workflows run only every 4–6 hours instead of every 5–15 minutes

[doublewater0804]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Workflow Configuration

Discussion Details

Repository: https://github.com/doublewater0804/ehs-management-portal

I have two independent GitHub Actions workflows:

1. ehs-weekly-report.yml — scheduled every 5 minutes.
2. ehs-schedule-diagnostic.yml — scheduled every 15 minutes.

Both workflows are enabled and exist on the default branch (main). Manual executions succeed.

However, scheduled executions occur only every 4–6 hours, with many expected runs missing.

Examples from November 5, 2026 (Taiwan time):

• Weekly report: 00:30, 06:06, 10:21.
• Diagnostic workflow: 01:23, 06:44, 10:57.

I have verified the cron syntax, workflow enabled status, default branch, and successful manual execution.

Could you investigate why scheduled workflow events are being skipped or not created for this repository?

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

[100rootrain]

I looked through your repo, and I don't think the problem is your configuration. It looks like it's on GitHub's side.

Your setup looks correct

• Both cron expressions (4-59/5 * * * * and 12,27,42,57 * * * *) are valid, and you've already avoided the top of the hour.
• Both workflows are active, they're on main (the default branch), and the repo is public and not a fork.
• This isn't concurrency either. Runs dropped by a concurrency group would still appear as cancelled, but your run history only has success runs. The missing runs were never created at all.

Why I think it's the scheduler

1. Your two workflows fire together. They run on different intervals (5 min and 15 min), but the runs come in pairs (Taiwan time):

   Weekly report (5 min)	Diagnostic (15 min)
   00:30	01:23
   06:06	06:44
   10:21	10:57

   If individual events were just being dropped under load, the gaps would be random for each workflow. Instead, it looks like schedule events for your repo are only being processed once every 4–6 hours, and both workflows get triggered in the same window.

2. Many people have reported the same thing since around Oct 31. For example, an hourly cron running every 4–8 hours (Hourly cron produces successful runs roughly 4–8 hours apart: what to check? #212101), a two-hour cron running every 3–9 hours (Two-hour scheduled workflow creates events only every 3–9 hours — how to diagnose missing triggers? #211723), and scheduled workflows that never trigger at all (Active scheduled workflow creates no schedule runs; workflow_dispatch succeeds #211816, Scheduled Actions events missing after 02:10 UTC on 2026-11-02 #211839, Scheduled workflows never trigger, but workflow_dispatch works #211937). The cron intervals differ, but the symptoms are the same.

3. GitHub Status shows several Actions incidents this week (Oct 30, and twice on Nov 4). They're all marked resolved, but the schedule delays are still happening.

GitHub's docs say schedule events are best-effort and can be delayed or dropped under high load. But 15-minute, hourly, and two-hour crons all slipping to the same 4–6 hour cadence looks more like a platform-wide scheduler backlog than ordinary delays. There isn't much you can change in your workflow to fix this.

Workaround if you need reliable timing

Trigger the workflow from an external cron service (cron-job.org, Cloudflare Workers Cron Triggers, etc.) through the workflow_dispatch API, using a fine-grained PAT with Actions: Read and write on this repo:

curl -X POST \
  -H "Authorization: Bearer $TOKEN" \
  -H "Accept: application/vnd.github+json" \
  https://api.github.com/repos/doublewater0804/ehs-management-portal/actions/workflows/ehs-weekly-report.yml/dispatches \
  -d '{"ref":"main"}'

One catch: scheduler.mjs returns MANUAL_TEST_ONLY whenever eventName !== 'schedule', so a dispatched run won't send the official report as your code stands now. You'd need to add a workflow_dispatch input (e.g. trigger: external-cron) and let runner.mjs treat that input the same as schedule.

[doublewater0804]

Thank you for your detailed investigation.

I would like to keep using GitHub Actions native scheduling rather than switching to an external cron service.

Could you help confirm:

1. Is GitHub aware of the current scheduled workflow delays?
2. Is there an official issue or incident tracking this problem?
3. Is there an estimated resolution time?
4. Is there any recommended workaround that still uses native GitHub Actions scheduling?

My scheduled workflows are still running only every 4–6 hours instead of their configured intervals.

Thank you for your help.

[100rootrain]

I'm a community member, not GitHub staff, so I can't speak for GitHub. Here's what I could find as of Nov 5, 08:40 UTC:

1. Is GitHub aware of it?
I haven't seen any official acknowledgment yet. None of the similar threads I've found (#212101, #211723, #211839, #211816, #211937) have a reply from GitHub staff.

2. Is there an official incident?
Not one specific to schedule delays. githubstatus.com has no open incidents right now. The Actions incidents on Nov 4 (#212066, #212076) are marked resolved, and none of their status updates mention scheduled workflows.

3. Is there an ETA?
None has been published.

4. Is there a native workaround?
There's no setting that forces the scheduler to fire on time, but you can make your workflow more tolerant of late runs. Your scheduleDecision already handles part of this. On the configured day, any scheduled run after the due time returns DUE, so a late run still sends the report that day.

The gap is at midnight. Once the date changes, the report counts as MISSED_WINDOW and won't be sent. Scheduled tests work the same way and become EXPIRED. With 4–6 hour gaps, an evening due time (say 20:00) could easily miss every run until after midnight. Two native options:

• Move the send time earlier in the day, so even a 6-hour delay still lands on the same date.
• Or allow catch-up for a fixed window after the due time (e.g. 12–24 hours) instead of cutting off at midnight. Your weekly lock (ALREADY_SENT) already prevents duplicates, so this should be safe.

You can keep the 5-minute cron as it is. It does no harm, and once the scheduler recovers you'll get the precise timing back.

To get this in front of GitHub, I'd also open a ticket at https://support.github.com and include the workflow names, your expected vs. actual schedule run times in UTC, and a few run IDs. Some people have had tickets closed and redirected to Community, but it's still the most direct way to report it. Linking this discussion in the ticket may also help.