Scheduled (cron) workflow never triggers on a brand-new private repo

[elenrimskaia]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Schedule & Cron Jobs

Discussion Details

Repository: elenrimskaia/marys-garden-blog (private, GitHub Free plan)
Workflow: .github/workflows/telegram-publish.yml

The workflow has both a schedule and a workflow_dispatch trigger:

on:
  schedule:
    - cron: "5,15,25,35 7,15,18 * * *"
  workflow_dispatch: {}

The workflow file was added/pushed to the default branch (main) on 2026-07-09 at 11:06 MSK (08:06 UTC, commit 99d9ab5). Since then:

• workflow_dispatch (manual "Run workflow") has succeeded twice.
• The schedule trigger has not fired even once, across more than 10 hours and 8+ expected cron matches (07:05/07:15/07:25/07:35 and 15:05/15:15/15:25/15:35 UTC).

At 15:15 UTC I pushed a trivial comment-only edit to the workflow file (commit fdd111c) specifically to try to force GitHub to re-register the schedule trigger, in case it simply hadn't been picked up yet on first add. That did not help either — still zero schedule-triggered runs as of 18:20 UTC (three more expected cron matches passed since that commit).

Things I've already ruled out:

• Actions permissions: "Allow all actions and reusable workflows", read/write workflow permissions — all enabled.
• Billing/plan: GitHub Free, current usage <$0.01, no unpaid balance, no quota exhausted.
• Account email verified, no account restrictions or banners.
• The workflow file on the default branch matches what's expected (viewed via file browser), cron syntax is standard 5-field, minutes deliberately offset from :00/:30 to avoid the documented high-load congestion window.
• No "workflow disabled due to inactivity" banner anywhere in the Actions UI.

Has anyone seen scheduled workflows simply never register on a freshly created private repo like this? Is there a known delay longer than a few hours, or something else I should check?

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

[ZackeryBradley]

Have you tried renaming the workflow file? This would force Github to treat it as a new workflow and re-register the schedule.

another option you could try it just deleting and recreating the workflow into a new commit.

Last question: would it be possible to make the repo public, wait a few minutes, and then perform an edit? If you do and then swap the repo back to private it may resolve the issue.

[Dasmat13]

Cron schedules silently not firing on private repos is a well-known GitHub Actions limitation. Here are all the reasons and fixes:

Reason 1: Inactive repo suppression (most common)

GitHub automatically disables scheduled workflows on repos with no recent activity (typically >60 days). But for brand new repos, the schedule sometimes does not activate until the first manual or push-triggered run.

Fix: Run the workflow manually once via workflow_dispatch, then the schedule activates:

on:
  schedule:
    - cron: "0 8 * * *"
  workflow_dispatch: {}   # <-- add this

Then go to Actions → your workflow → "Run workflow" button.

Reason 2: Default branch mismatch

Schedule triggers only work on the default branch (usually main). If your workflow file is on a non-default branch, it will never fire.

Fix: Ensure .github/workflows/your-workflow.yml is committed to main (or whatever your default branch is set to in Settings → General).

Reason 3: New repo / new account queue priority

GitHub deprioritizes schedule execution for new repos and new accounts. Initial delays of 12–48 hours are normal.

Reason 4: Free plan private repo limits

Free plan: 2,000 Actions minutes/month for private repos. Check Settings → Billing — if you've hit the limit, workflows won't start.

Recommended workflow template for reliable scheduling:

on:
  schedule:
    - cron: "0 8 * * *"   # 8AM UTC daily
  workflow_dispatch: {}    # manual trigger as fallback
  push:
    branches: [main]       # also run on push to confirm it works

Quick test: Commit the workflow_dispatch trigger, then manually run it once. If it succeeds, your schedule will start working within 24 hours.