Scheduled workflows never trigger, but manual runs succeed

[Nittom]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Schedule & Cron Jobs

Discussion Details

Hello GitHub Support,

My GitHub Actions scheduled workflows are not triggering.

Repository: Nittom/threads-auto (private)
Default branch: main

Affected workflows:

• .github/workflows/daily.yml
• .github/workflows/schedule-test.yml

Details:

• Both workflows are enabled.
• Manual runs using workflow_dispatch succeed.
• Scheduled runs are not appearing in the Actions history.
• The test workflow uses cron: 17,47 * * * *.
• I have repeatedly changed the cron expressions and committed them to main.
• At 15:26 JST on November 10, 2026, the expected 15:17 scheduled test run was still missing.
• Another workflow (insights-test.yml) did trigger via schedule at 06:48 JST on November 10, but that run failed.

Questions:

1. Are these schedule triggers correctly registered?
2. Are the scheduled events being dropped, delayed, or suppressed?
3. Is there a repository or workflow setting causing this?
4. What should I do to restore scheduled execution?

Previous scheduled run:
https://github.com/Nittom/threads-auto/actions/runs/42705966491

Please help investigate the scheduler rather than the workflow scripts, as manual execution succeeds.

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]

The repo is private, so I can't look at it, but your own data already answers some of this:

The scheduler isn't blocked for the repo. insights-test.yml fired on schedule at 06:48 JST, so scheduled events reach this repository. If a setting were suppressing schedules, that run wouldn't exist either. It failed, but that's a separate problem in its own job.

A run that's 9 minutes late isn't missing yet. The schedule trigger is best-effort. The docs say it can be delayed under high load and that queued runs can be dropped. Delays of 15–60 minutes are common, so checking at 15:26 for a 15:17 run is too early to tell. Picking :17 and :47 instead of :00 was the right call.

Stop re-editing the cron. Every push that changes the schedule block re-registers the trigger, and repeated edits keep resetting it. Push one final version to main, leave it alone for a few hours, then check:

gh run list -R Nittom/threads-auto --workflow schedule-test.yml --event schedule

If nothing shows up after a few hours, check the YAML. A wrong on: block often still lets workflow_dispatch work. It should look exactly like this, with schedule as a list item:

on:
  workflow_dispatch:
  schedule:
    - cron: "17,47 * * * *"

Also, cron runs in UTC. That doesn't matter for 17,47 * * * *, but if daily.yml assumes JST it will fire 9 hours off (09:00 JST is 0 0 * * *).

If you need exact timing, don't rely on schedule. Since your manual runs work, have an external scheduler (cron-job.org, Cloud Scheduler, etc.) call the dispatch API:

POST https://api.github.com/repos/Nittom/threads-auto/actions/workflows/daily.yml/dispatches
Authorization: Bearer <fine-grained PAT with Actions: write on this repo>
{"ref": "main"}

That uses the same code path as your manual runs, so it won't be delayed or dropped.

[kittimzhe]

Since it's a private repo the runs can't be verified from outside, but "manual dispatch works, schedule never fires" in a private repo has a short prioritized checklist — the first two are the ones people miss:

1. 60-day repository inactivity: scheduled workflows are auto-disabled in repositories with no activity for 60 days. Re-enabling the workflow does not retroactively matter — but any push resets the clock. If threads-auto sat quiet before you added these workflows, trigger one manual push to main and watch the next cron slot.
2. Included-minutes exhaustion (private repos only): scheduled runs consume Actions minutes; when the monthly included minutes are gone and the spending limit is $0, schedule events stop being delivered. Manual dispatch succeeding argues against a hard block, but check Settings → Billing → Usage to be certain — exhaustion can hit exactly at the schedule-delivery layer first.
3. Then the platform reality: scheduled workflows are best-effort and silently dropped under load — a dropped tick leaves no run object, so runs?event=schedule showing nothing is expected for drops, not proof of non-registration. Judge over a 48h window, not per-slot.

Family reference with the discriminator (compare each run's created_at against the cron slot to separate delay from drop): #209399, #209438, #211879, #212402 — the last one has a measured 97% drop rate on a 10-minute cron from just yesterday, so heavy dropping is active in this window.

[Nishant-Af]

To separate “delayed” from “dropped”, log it instead of eyeballing the Actions tab. Add this to the schedule-test workflow so every run records how late it was:

yaml

• name: Log schedule lag
  run: |
  echo "event=${{ github.event_name }}"
  echo "started=$(date -u +%H:%M:%S)"

Then after 24-48h, list only scheduled runs with:

gh run list -R Nittom/threads-auto --workflow schedule-test.yml --event schedule --limit 100 --json createdAt

Compare each createdAt to its :17/:47 slot. Late-but-present means load delay. Gaps with no run at all mean dropped ticks, which matches the platform-wide behavior others in this thread describe. Also worth moving off :17/:47 to something like :08/:38, since slots near the quarter-hour marks tend to be busier.