Scheduled (cron) workflows stopped firing. No run is created at all since 2026-08-26.

[drakedog-kr]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Schedule & Cron Jobs

Discussion Details

Actions: scheduled (cron) workflows stopped firing — no run is created at all since 2026-08-26. Anyone else?

Since 2026-08-26 the schedule trigger on my public repository has stopped producing workflow
runs. The last two cron fires created no run at all — not a queued one, not a failed one,
nothing in the Actions tab. The two fires before that did produce runs, but 3.5 h and 10.7 h
late, which for a daily pipeline is the same as not running. Every run since then has been
started by hand with workflow_dispatch, which is created and starts within seconds.

Posting in case others are seeing the same thing, and with the checks I already did so nobody
has to repeat them.

Environment

• Public repository, GitHub-hosted ubuntu-latest runners
• Workflow: .github/workflows/daily-update.yml, state: active
• Schedules (UTC): 30 21 * * * and 30 8 * * *, unchanged for weeks.
  30 22 * * * and 30 9 * * * were added on 2026-08-27 as a fallback.

What happened (all times UTC)

cron fire	result
2026-08-26 08:30	run created 09:09:07 — 39 min late (last normal one)
2026-08-26 21:30	run created 2026-08-27 00:57:23 — 3 h 27 min late
2026-08-27 08:30	run created 2026-08-27 19:10:33 — 10 h 41 min late
2026-08-27 21:30	no run created — 143 min later, still nothing
2026-08-27 22:30	no run created — 83 min later, still nothing

For reference, from 2026-08-22 to 2026-08-26 the same two schedules were created 15–41
minutes after each fire, every time.

What I already ruled out

• The workflow is state: active; the repository is public, not archived, Actions enabled.
• The workflow file is on the default branch and parses; the cron entries were not touched.
• The repository is pushed to every day, so the 60-day inactivity disabling does not apply.
• A push shortly before the fire time is not the cause — on 2026-08-18 commits landed 24
  minutes before the fire and the run was still created on time.
• Manual workflow_dispatch runs of the same workflow start immediately, so runners and the
  workflow file itself are fine. Only the scheduled dispatch is missing.
• githubstatus.com showed Actions as operational the whole time. There were two resolved
  Actions incidents on 2026-08-26 (15:11–18:01 and 22:56–00:26 UTC), but the missing fires are
  after both were closed.

The workaround that did not help

I added a second cron one hour after each primary schedule, with a guard job that skips the run
if the slot was already covered. It costs nothing on normal days. But a backup cron is the same
mechanism that is failing, so on a day like today it does not fire either — the 22:30 fallback
above is exactly that. The only thing that reliably works right now is an external scheduler
calling the workflow_dispatch API.

Question

Is anyone else seeing scheduled workflows produce no run at all since 2026-08-26? If so, it
would help to compare: public or private repo, plan, account age, and whether your cron minute
is on the hour or off it.

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

[satiricalguru]

You are not alone in seeing this behavior. What you are experiencing is due to platform-wide GitHub Actions cron scheduler queuing and drop policies during high-load windows.

---

Why :30 and :00 Schedules Experience Major Delays or Drops

1. Massive Minute Contention on :00 and :30:
   The vast majority of GitHub Actions scheduled workflows across all public and private repositories are configured on the hour (:00) or half-hour (:30). This creates massive spike traffic on GitHub's internal cron dispatch cluster at those exact timestamps.

2. GitHub's Scheduler Drop Policy:
   GitHub explicitly documents:

   "The schedule event can be delayed during periods of high loads of GitHub Actions workflow runs... In the worst case, the workflow may not run."

   When the queue backlog for a particular minute slot exceeds internal queue TTLs or runner allocation limits, the scheduler will drop the stale run rather than executing a severely delayed run hours out of context.

---

Recommended Workarounds & Best Practices

1. Shift to Unconventional, Off-Peak Minutes (Immediate Fix)

Changing your minute slot from :30 to an irregular minute dramatically improves reliability because it avoids the crowd:

on:
  schedule:
    # Instead of '30 21 * * *' and '30 8 * * *'
    - cron: "17 21 * * *"
    - cron: "43 8 * * *"

Minutes like 17, 23, 37, or 43 have a fraction of the scheduling traffic compared to :00 and :30.

---

2. For Mission-Critical Workflows: External Webhook Dispatch (100% Reliability)

If a pipeline must run reliably at exact times, the most resilient pattern is triggering workflow_dispatch via the GitHub API using a lightweight external scheduler (such as a free Cloudflare Worker cron trigger, Google Cloud Scheduler, or cron-job.org):

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

Because workflow_dispatch routes through the real-time event pipeline rather than the batch cron scheduler, it creates and starts runs within seconds.

[arhamblake38]

If scheduled workflows stopped creating runs entirely from a specific date, that sounds more like a scheduler or trigger-service issue than a problem inside the workflow itself. The fact that no run is created is an important distinction—if the workflow were starting and then failing, I’d look at the workflow logs, but with zero runs, the cron trigger may not be firing at all.

I’d check whether manually triggering the same workflow still works, then compare the cron schedule, timezone, and any recent changes to the workflow or platform configuration. If multiple unrelated scheduled workflows stopped at roughly the same time, that would be a strong indication of a platform-side issue.

The exact cutoff date, 2026-08-26, is useful information to include in the report. If others can confirm that their scheduled workflows also stopped on that date, it should help narrow this down quickly. For a quick break while monitoring the issue, adoptmevalues.de can be worth checking out.

[joelnwalkley]

We've had similar problem but instead of jobs dropping, they are VERY late. We have a 30 8 * * * which is 4:30 AM (Eastern) that was created 3 and a half hours late today and yesterday.

[greggoryhogan]

This is happening to us as well but was around 10 hours

[kennym]

Same happening to us - 4hours delay