Subject: Scheduled (cron) workflow triggers not firing at all on a private repo

[kimdumi]

🏷️ Discussion Type

Question

💬 Feature/Topic Area

Schedule & Cron Jobs

Discussion Details

Repository: kimdumi/news_monitor (private)

Summary

The schedule trigger for GitHub Actions workflows in this repository has stopped firing entirely. workflow_dispatch runs work normally every time, but no schedule-triggered run has occurred since 2026-06-26 21:55:44 UTC (run id 28267489709) — over 4 hours as of this writing.

What I've tried

1. Changed the cron expression from */30 * * * * to 7,37 * * * * to avoid the documented top-of-hour high-load window. No effect — still zero schedule runs.
2. Disabled and re-enabled the workflow (gh workflow disable / gh workflow enable) to force re-registration. No effect.
3. Added a second, completely separate workflow (watchdog.yml) with its own independent schedule (23 * * * *), created fresh after the above steps. This brand-new workflow has also never fired on its schedule, missing its first scheduled run at 02:23 UTC with no prior history of any kind.

Point 3 rules out anything specific to the original workflow's YAML content or its particular cron offset — it strongly suggests the scheduled-trigger registration for this repository (or account) is broken at the platform level, not something I can fix from the repository side.

Confirmed not the cause

• No active incident is listed on githubstatus.com for Actions at the time of writing.
• Repo is not archived/disabled (disabled: false via API).
• Workflow state is active for both workflows (via gh workflow list / API).
• No stuck/queued runs blocking on the concurrency group (all recent runs show completed).

Request

Could you check whether scheduled-workflow event delivery is registered/functioning correctly for this repository (kimdumi/news_monitor)? Happy to provide run IDs, workflow IDs, or anything else needed.

Workflow IDs: news-monitor = 302427455, news-monitor-watchdog = 303023539

[cookesan]

Given what you have already checked, I would separate this into two buckets: things still worth verifying locally, and things only GitHub can verify for a private repository.

Repository-side checks:

1. The workflow file is on the repository default branch.
2. The cron is in UTC and has at least the 5-minute minimum interval.
3. The workflow state is active.
4. The actor associated with the scheduled workflow is still an active account.
5. The workflow was not disabled and then re-enabled without a commit that changes the cron line.

The first one is easy to miss: schedule only runs from the default branch, using the latest commit on that branch. A manual workflow_dispatch run can work from a selected branch/ref, so it does not fully prove that the scheduled event is registered against the default branch copy of the file.

The docs also say scheduled runs can be delayed during high load, and may even be dropped if load is high enough. Moving off */30 to something like 7,37 * * * * was the right mitigation for the top-of-hour case, but it is not a guarantee of exact delivery.

For your specific facts, the strongest signal is that a brand-new independent scheduled workflow also missed its first run while manual dispatch still worked. If both workflow files are definitely present on the default branch and both show active, there probably is not much more you can fix from YAML.

For a support ticket, I would include:

repository: kimdumi/news_monitor
workflow ids: 302427455 and 303023539
last successful scheduled run id: 28267489709
the exact UTC schedule times that were missed
the default branch name and current default-branch SHA
output showing both workflows are active
confirmation that workflow_dispatch still runs

Since the repository is private, community members cannot inspect the event delivery state. After the default-branch and actor checks, this is likely something GitHub Support would need to look at from their side.

[kimdumi]

Thanks for the detailed checklist — I went back and verified each item properly (fetched the live file content via the API rather than trusting local state):

1. Workflow files are on the default branch (main), confirmed via GET /repos/.../contents/.github/workflows (which resolves against the default branch) and a matching local origin/main HEAD SHA.
2. Cron expressions, fetched live from the API content (not from my local git history): news.yml → 7,37 * * * *, watchdog.yml → 23 * * * *. Both UTC, both well above the 5-minute minimum.
3. gh workflow list shows active for both workflow IDs (302427455 and 303023539).
4. The committer/owner account is not suspended (suspended_at: null).
5. On this one I have to correct something I said earlier in this thread: I'd claimed workflow disable/enable "fixed" it, but checking the actual timestamps, the disable/enable happened ~28 minutes after the cron-line-changing commit, with no commit accompanying the disable/enable itself. The schedule didn't actually start firing again until ~13 hours later. So disable/enable without an accompanying commit very likely did nothing — the eventual recovery is better explained by one of the several other commits pushed in between (consistent with the "any commit to the default branch resyncs scheduled workflows" behavior from the Jan 2026 incident) or by the platform-side issue simply clearing on its own.

Net result: all five checks pass, nothing fixable from the repo side. For the record in case anyone hits this later — the schedule trigger was completely silent (zero schedule-triggered runs, including for a brand-new independent workflow) for about 17 hours (last good run 2026-06-26 21:55:44 UTC, recovered 2026-06-27 15:04:34 UTC), then started firing normally again without any specific repo-side action confirmed to have caused it. workflow_dispatch worked the entire time. Appreciate the thorough checklist — will file a support ticket with these specifics if it recurs.

[farhan2t24]

Based on everything you've tested, this doesn't sound like a workflow configuration issue. The fact that:

workflow_dispatch works consistently,
multiple independent scheduled workflows never fire,
you've changed the cron schedule,
disabled/re-enabled the workflows,
and verified the repository and workflow states,

strongly suggests the problem is with scheduled event delivery rather than your YAML.

Unfortunately, GitHub Community members can't inspect the backend scheduler or verify whether cron registrations are healthy for a specific repository. This is something only GitHub Support can investigate.

I'd recommend opening a GitHub Support ticket and including the repository name, workflow IDs, the last successful scheduled run ID, and the troubleshooting steps you've already performed. That should give the support team enough information to check whether scheduled events are being generated for your repository

[rehuux]

This is a well documented issue. The fact that a brand new watchdog workflow also never fired its first scheduled run confirms this is likely a platform level problem rather than something wrong with your YAML configuration.

What you can do right now

1. Make a dummy commit to your default branch

Scheduled workflows are registered or re registered when the workflow file is pushed to the default branch. If your repository has been idle with no commits for a while, the schedule registration can become stale. Push a trivial commit (even an empty one) to force re registration.

2. Verify Actions permissions for private repositories

Go to Settings → Actions → General and ensure:

· Actions are enabled (Allow all actions or Allow select actions)
· Workflow permissions are set correctly

3. Check your Actions minutes usage

Private repositories consume included minutes. If your account has exhausted its free minutes, scheduled runs may be blocked while manual triggers still work. Check your usage at the repository or account level.

4. Contact GitHub Support directly

Community members cannot access internal event delivery logs. Open a ticket at https://support.github.com/contact and include:

· Repository: kimdumi/news_monitor
· Workflow IDs: 302427455 and 303023539
· Last successful scheduled run timestamp
· A link to this discussion

One more observation

Your last run was at 21:55:44 UTC. The cron expression */30 * * * * should fire at :00 and :30. Running at :55 is unusual and may indicate that run was manually triggered or delayed, which could be another clue that the schedule registration is broken.