Scheduled workflow (cron) never triggers via 'schedule' event — private repo, Free plan, never fired since creation

[kleber-br]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Schedule & Cron Jobs

Discussion Details

Summary

Scheduled workflows in my repository have never triggered autonomously via the schedule event since the repository was created (2026-07-19). workflow_dispatch works correctly on the same workflows.

Repository details

• Type: Private, non-fork, Free (Standard) plan
• Created: 2026-07-19
• Default branch: master
• All workflows confirmed state: active via API

What I've verified

• ✅ Valid cron syntax (verified with crontab.guru)
• ✅ Workflow files committed directly to the default branch (master)
• ✅ Renamed workflow file (daily.yml → cron_diario.yml) to force scheduler reindexing
• ✅ workflow_dispatch triggers work correctly on the same workflows
• ✅ No duplicate workflows with competing schedules
• ✅ Repository not archived, not disabled, not a fork

Missed schedule cycles (all UTC)

Time (UTC)	Workflow	Cron
2026-07-20 00:00	cron_diario.yml	0 0 * * *
2026-07-21 00:00	cron_diario.yml	0 0 * * *
2026-07-22 00:00	cron_diario.yml	0 0 * * *
2026-07-22 07:00	cron_diario.yml	0 7 * * * (temporary test)
2026-07-22 08:25	teste_cron.yml	25 8 * * * (minimal test)

Minimal test workflow (also failed)

To isolate the issue from our complex workflow, I created a bare-minimum test:

name: Teste cron minimalista
on:
  schedule:
    - cron: "25 8 * * *"
  workflow_dispatch:
jobs:
  ping:
    runs-on: ubuntu-latest
    steps:
      - run: echo "cron disparou em $(date -u)"

This workflow — no Python, no secrets, no dependencies, just echo — also failed to trigger at 08:25 UTC on 2026-07-22.

API evidence

gh api repos/{owner}/b3-alertas-pro/actions/runs?event=schedule
→ total_count: 0

Zero schedule-triggered runs across all workflows since repository creation.

Question

Is there a known delay for the schedule event to activate on newly created private repositories on the Free plan? Is there any action required to enable 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. ⭐

[Hamzaishappy786]

Hello brother,

First off, thank you for providing such a masterclass in issue reporting! Your thorough troubleshooting (checking the default branch, forcing reindexing, isolating a minimal workflow, and providing API evidence) rules out 99% of the usual culprits.

To answer your questions directly: No, there is no official documented delay or action required to "enable" schedules on private Free repositories. However, what you are experiencing is a known, frustrating quirk regarding GitHub's shared infrastructure for the schedule event.

Here is what is likely happening and how to address it:

1. The GitHub Actions Scheduler is "Best Effort"

GitHub explicitly states that the schedule event runs on a best-effort basis and can be heavily delayed, especially during peak hours (like midnight UTC, which your main workflow targets). On the Free plan, cron jobs have the lowest priority in the global queue. If the queue is backed up, a run can be delayed so long that it is effectively dropped entirely.

2. The "Cold Start" Hibernation Bug

There is a known, long-standing issue where the scheduler occasionally fails to register cron jobs for brand-new repositories (especially private ones on Free tiers) until a code-based event "wakes up" the repository's action runner registration. While workflow_dispatch works, it doesn't always force the cron daemon to pick up the repo metadata.

---

🛠️ Recommended Steps to Force-Start It

Since your configuration is flawless, try these tricks to force GitHub's backend scheduler to recognize your repository:

1. Change the cron to a high-frequency, non-peak time:
   Midnight UTC (0 0 * * *) is the single most congested minute on GitHub Actions. Try a completely random, non-peak time for a test, like 47 14 * * * (14:47 UTC).
2. Trigger a code-based event:
   Add a temporary push trigger to your default branch (master) on your minimal test workflow:

   on:
     push:
       branches: [ master ]
     schedule:
       - cron: "47 14 * * *"
      Push a dummy commit to trigger it. Historically, a successful push-triggered run does a better job of "priming" the repository's scheduler bindings than workflow_dispatch.

3. The "Nuclear Option" (Toggle Actions off/on):
   Go to Settings -> Actions -> General. Under Policies, select Disable actions, save it, wait a minute, and then change it back to Allow all actions and reusable workflows. This forces a hard reset on the repository's Actions metadata.

If you try a non-peak random time following a push trigger and it still fails to run after a couple of cycles, it means your repository is stuck in a backend queue dead-zone. In that case, you'll need to open a formal ticket with GitHub Support so an engineer can manually kick the scheduler backend for your specific repository ID.

Let me know my brada, if changing to a non-peak time or toggling the Actions setting wakes it up!

[Arpitha2697]

Hi @kleber-br,

Here are the most common reasons why a scheduled (cron) workflow doesn't trigger in a private repository on a Free plan:

1. GitHub Actions Minutes Limit: Private repositories on the Free plan are limited to 2,000 free minutes per month. If your account or organization has exhausted its monthly allotment, scheduled workflows will not run. You can check your remaining balance in Account Settings > Billing & plans.
2. Repository Inactivity: GitHub automatically disables scheduled workflows in repositories that have had no commit activity for 60 days. If the repo has been idle, you need to manually re-enable the workflow under the Actions tab or push a new commit.
3. Must Be on the Default Branch: Scheduled workflows (on: schedule) only execute if the workflow .yml file exists on the default branch (usually main or master). If it’s only in a feature branch, it won't fire.
4. Initial Delay / High Load: Scheduled triggers run on a best-effort basis and can experience significant delays (sometimes 30+ minutes) during peak hours.

Hope this helps solve the issue!

[Arpitha2697]

Hi @cartergray234 ,

Given the API evidence (total_count: 0) and the fact that even a minimal workflow fails to trigger via schedule, your repository's cron daemon binding is likely stuck on the backend.

Since all standard fixes (like verifying the master default branch and using workflow_dispatch) have been exhausted, you should submit a ticket to GitHub Support with the following details:

1. Repository Name & Visibility: b3-alertas-pro (Private / Free Plan)
2. Default Branch: master
3. API Response Evidence: Include the JSON snippet showing total_count: 0 for event=schedule.
4. Missed Timestamps: List the specific missed UTC execution times from your log.

GitHub Support engineers can manually re-sync the scheduler daemon for your specific repository ID.

[KhyFee]

Your write-up already rules out a lot of YAML footguns. On private + Free, the usual remaining causes are:

1. Actions minutes / spending limit for private repos — schedules are easy to starve; workflow_dispatch can still confuse the picture.
2. Confirm the minimal cron workflow is on the default branch and has actually been merged (not only on a feature branch).
3. After each UTC cron window, filter Actions by event=schedule. If it stays at 0 forever, it is dispatcher-side rather than a failed job.

Given you tried a minimal workflow that never fired either, I would treat this as a Support case with: plan type, private, default branch, workflow path/SHA, and the empty schedule filter. The community can only re-list the checklist past this point.