GitHub Actions schedule not triggering; manual runs succeed

[BubuWang996]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Schedule & Cron Jobs

Discussion Details

Hello GitHub Support,

My GitHub Actions workflow has a schedule trigger, but no scheduled runs appear in the existing run history. Manual workflow_dispatch runs succeed.

Repository:
https://github.com/BubuWang996/trendradar-x

Workflow:
https://github.com/BubuWang996/trendradar-x/actions/workflows/crawler.yml

Configuration:

• Default branch: master
• Workflow file: .github/workflows/crawler.yml
• Cron: "3-59/5 * * * *"
• Latest commit: 2dd251e67a11ba6f0ed432641fd02d132bbe543b
• The workflow is enabled. Its menu shows "Disable workflow".

As of October 10, 2026, approximately 11:06 UTC+8:

• All five existing Get Hot News runs were triggered manually.
• No schedule-triggered runs are present.
• No queued or in-progress runs were present in the API response.

Latest successful manual run:
https://github.com/BubuWang996/trendradar-x/actions/runs/38014704974

This run was created on October 10 at 01:50:14 UTC and completed successfully in approximately 29 seconds.

I understand scheduled workflows may be delayed or dropped during high load. Could you investigate why this enabled workflow is not producing scheduled runs, and check for any repository or account restrictions affecting schedule events?

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

[mohittguptaa]

I checked your repo: the workflow is on the default branch (master), the cron syntax 3-59/5 * * * * is valid, and the repo isn't a fork — so the config itself is fine. A few things are likely in play:

1. The schedule may not have been registered. Schedules are registered when the workflow file changes on the default branch. On a brand-new repo (yours was created Oct 9) this sometimes silently doesn't happen. Fix: push a trivial change to .github/workflows/crawler.yml on master (e.g. edit a comment), or go to Actions → Get Hot News → … → Disable workflow, then Enable workflow again. This re-registers the schedule.

2. 5-minute crons are best-effort. GitHub drops scheduled runs under load, and high-frequency schedules on new repos get dropped most often. Even when working, expect 5–30 min delays and skipped slots. If you really need every 5 minutes, use an external trigger (e.g. a cron job / Cloudflare Worker calling the workflow_dispatch API) — your manual runs already prove that path works.

3. Not a cause, but note: if: github.ref == 'refs/heads/master' is fine for schedules since they always run on the default branch.

If after step 1 you still see zero schedule runs for 24h, that points to an account/repo-level restriction and only Support can check that — mention you already re-registered the schedule so they don't send you the self-service reply.

[MalikAhed]

Your cron expression is valid and the workflow is on the default branch. Two checks are especially important here: GitHub only schedules workflows from the default branch, and a workflow’s schedule can be disabled after repository inactivity, so confirm the Actions page still shows the workflow enabled and that the repository has not crossed that inactivity window. For a newly created repo, push a no-op/comment change to .github/workflows/crawler.yml on master and wait through a full matching minute boundary; that forces GitHub to re-register the schedule. Then query the workflow runs API with event=schedule and save the default-branch SHA, workflow URL, and timestamps. If there are still zero scheduled runs after re-registration, open GitHub Support with that evidence because a repository/account-side scheduler issue cannot be diagnosed from the workflow file alone. Official reference: https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#schedule . If this resolves it, please mark the reply as the accepted answer.

[kittimzhe]

Live update with API data: as of Oct 12, the schedule is working. GET …/actions/workflows/crawler.yml/runs?event=schedule returns 10 schedule runs, all conclusion: success — the first at 2026-10-10T07:46Z (roughly 5 hours after your check at 11:06 UTC+8), the latest at 2026-10-12T00:45Z. So the registration did land and delivery began within hours — the same late-delivery pattern seen platform-wide in this window (#209399 documented runs created 5h+ past the last permitted cron time; #209438 saw a first fire 3h late).

One expectation worth recalibrating, though: your cron 3-59/5 * * * * requests ~12 runs/hour, but actual delivery is roughly one run every 4 hours (07:46 → 13:59 → 18:22 → 21:53 → 00:34 …). Scheduled workflows are documented as best-effort — they can be delayed or dropped during periods of high usage — and high-frequency crons on brand-new repos get the lowest scheduling priority. The missing windows won't backfill, and full-rate 5-minute delivery isn't something Actions scheduling commits to.

If you genuinely need every-5-minute execution, the reliable pattern is an external scheduler hitting workflow_dispatch through the API — that path bypasses the scheduler queue entirely, and your successful manual runs already prove it works on this repo.