Scheduled workflow (cron) never triggers — manual dispatch works fine, confirmed not repo-specific

[BuyRightAdvocates]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Schedule & Cron Jobs

Discussion Details

Repository: BuyRightAdvocates/bra-newsletter
Workflow file: .github/workflows/daily.yml
Default branch: main
Account: personal (Free plan, not an organization)

Summary:
A scheduled GitHub Actions workflow in this repository has never once triggered automatically via its cron schedule, across multiple different valid cron configurations tested over several days. Manual triggering via workflow_dispatch works reliably every time. I've since confirmed this isn't specific to this one repository either — details below.

What I've tried and confirmed:

Repository is not a fork (fork count is 0)
Default branch is main, workflow file is correctly located at .github/workflows/daily.yml
Actions permissions are set to "Allow all actions and reusable workflows"
Workflow permissions are set to read-only for contents/packages (intentional — the workflow only makes outbound API calls to external services and never writes back to the repo)
Cron syntax has been validated as correct each time
Tried several different cron values over multiple days, including:
0 21 * * 1-5
35 3 * * *
0 21 * * 0-4
*/5 * * * * (left running for 30+ minutes as a high-frequency diagnostic test — zero runs were produced in that window)
Made a trivial resync commit to the default branch (small edit to README.md) — no change
Toggled Actions off and back on for the repository (Settings → Actions → General) — no change
workflow_dispatch (manual "Run workflow" button) has worked correctly on every single attempt throughout this entire process

Additional test — new, separate, public repository, same account:
To rule out anything specific to this repository, I created a brand-new, minimal, public test repository under the same account with the simplest possible workflow (a single echo step, no secrets, no dependencies) on a */5 * * * * schedule. After 20+ minutes, this also produced zero scheduled runs, while workflow_dispatch on the same test repo worked immediately. This suggests the issue is tied to the account rather than to bra-newsletter's specific configuration or history.

One more detail that might be relevant: two runs did appear in the bra-newsletter Actions history labelled as "scheduled" — one on 31 July at 18:10 AEST and one on 1 August at 10:13 AEST — but neither time matches any cron value configured at that point, and both occurred on days when I was actively editing the workflow file. Since then, no scheduled run has fired at all in that repository, despite several further reconfigurations.

Given manual dispatch works perfectly on both repositories, every repository-level setting checks out correctly, and the problem reproduces on an entirely separate, minimal, public repository under the same account, this looks like it could be an account-level or backend issue with schedule event registration, rather than a configuration problem on my end.

Current live cron on bra-newsletter (at time of writing): 48 20 * * 0-4 (intended to fire at 6:48am AEST, Monday–Friday)

Has anyone else run into this exact pattern — schedule never firing at all (not just delayed) while workflow_dispatch works fine? Happy to share any further detail, run IDs, or logs that might help.

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

[KhyFee]

Checklist when workflow_dispatch works but schedule never does

Your setup (default branch, not a fork, dispatch OK) is what most people get right — so this is usually GitHub runtime / plan rather than YAML.

1. UTC + low guarantee — cron is evaluated in UTC and runs are best-effort. They can lag minutes or get delayed during load. If you need clock-accurate work, self-host a timer that hits repository_dispatch / a small script.
2. Spending limit / minutes — on Free personal accounts, when private-repo Actions minutes or the spending limit is exhausted, scheduled jobs tend to go silent while manual dispatch still works if you retry when capacity is free. Check Settings → Billing → Actions.
3. Inactivity — Scheduled workflows can stop for idle repos without recent activity. Push a tiny commit, wait a day, don’t thrash every five minutes.
4. Don’t use high-frequency crons to “debug” — */5 * * * * often piles delayed runs or is throttled. Use something daily / hourly for a clean signal:
   cron: '0 9 * * *' # 09:00 UTC
5. Confirm registration — After the file is on main, open Actions → workflow and ensure schedules aren’t disabled. Search All workflows for “skipped” / waiting.

If after a daily cron + available minutes you still get zero scheduled attempts in the Actions log for 48h, open Support with: free vs pro, private/public, last push date, and a link to the empty schedule history.

I’ve hit the same “dispatch green / schedule empty” pattern mainly from billing limits and repo idle — not from invalid on.schedule syntax when workflow_dispatch already runs.

[tomm1990]

when workflow_dispatch works everywhere but schedule never produces a run at all (not just late - literally zero attempts), and you reproduced it on a second minimal public repo on the same account, that stops looking like cron yaml and starts looking like schedule dispatch isn’t registering for the account.

do this first - grab evidence for a support ticket (run as the account owner):

# both repos - confirm the workflow is active and see what GitHub thinks is registered
gh api repos/BuyRightAdvocates/bra-newsletter/actions/workflows --paginate \
  --jq '.workflows[] | {id, name, path, state}'

gh api repos/BuyRightAdvocates/<your-test-repo>/actions/workflows --paginate \
  --jq '.workflows[] | {id, name, path, state}'

# recent runs - note whether ANY scheduled event shows up (vs only workflow_dispatch)
gh api 'repos/BuyRightAdvocates/bra-newsletter/actions/runs?per_page=30' \
  --jq '.workflow_runs[] | {id, event, status, conclusion, created_at, workflow_id}'

if event is never schedule across days of cron on main, that’s the smoking gun: GitHub isn’t enqueueing schedule events for this account even though manual dispatch is fine.

if billing is clean (Actions spending limit enabled, minutes available on free - your test repos are public so minutes aren’t the usual private-repo cap issue) → open GitHub Support with:

• both repo urls
• “dispatch works, schedule never creates a run on public minimal repo”
• the gh api output above
• one workflow_dispatch run id that succeeded + proof zero schedule runs exist

community can’t flip account-level schedule registration back on - support has to repair that backend state.

if that still fails - link this thread plus any similar ones you find; staff sometimes batch-fix account-level schedule bugs when the repro is this clean.