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

kimdumi · 2026-06-27T03:53:40Z

kimdumi
Jun 27, 2026

🏷️ 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

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.
Disabled and re-enabled the workflow (gh workflow disable / gh workflow enable) to force re-registration. No effect.
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 · 2026-06-27T17:16:57Z

cookesan
Jun 27, 2026

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.

1 reply

kimdumi Jun 28, 2026
Author

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):

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.
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.
gh workflow list shows active for both workflow IDs (302427455 and 303023539).
The committer/owner account is not suspended (suspended_at: null).
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.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

GitHub Community

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

Uh oh!

{{title}}

Uh oh!

Replies: 1 comment 1 reply

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

GitHub Community

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

Uh oh!

kimdumi Jun 27, 2026

🏷️ Discussion Type

💬 Feature/Topic Area

Discussion Details

Summary

What I've tried

Confirmed not the cause

Request

Replies: 1 comment · 1 reply

Uh oh!

cookesan Jun 27, 2026

Uh oh!

kimdumi Jun 28, 2026 Author

kimdumi
Jun 27, 2026

Replies: 1 comment 1 reply

cookesan
Jun 27, 2026

kimdumi Jun 28, 2026
Author