Scheduled workflows stopped firing — no run objects created, workflow_dispatch works

[shinkunda]

Hello,

Scheduled (on.schedule) workflow runs have completely stopped being created in my repository. This is not a job failure and not a queued/delayed run — no workflow run object is created at all. Both scheduled workflows in the repository are affected.

I have already ruled out every repository-side and account-side cause I am aware of, and I have confirmed that manually dispatched runs still work perfectly. I believe the cron schedule registration for this repository has been lost on GitHub's side and is not being re-created.

---

1. Environment

Item	Value
Repository	shinkunda/my-virtual-company
Visibility	Private
Plan	GitHub Free
Default branch	main
Affected workflows	hourly-snapshot (.github/workflows/hourly-snapshot.yml) daily-vods (.github/workflows/daily-vods.yml)
Cron — hourly-snapshot	23 * * * * (every hour at :23 UTC)
Cron — daily-vods	17 4 * * * (daily at 04:17 UTC)

Note: this repository was renamed on 2026-08-27 (details in section 4). Its previous name was shinkunda/HypeLog.

---

2. Symptom

• Last scheduled run: hourly-snapshot #157 — 2026-08-26 17:37 UTC (2026-08-27 02:37 JST). It completed successfully.
• Since then, no scheduled run has been created for either workflow.
• As of 2026-08-28 03:02 UTC, that is approximately 33 hours and 33 consecutive missed hourly slots, plus 1 missed daily slot (daily-vods at 2026-08-27 04:17 UTC).
• The newest run of any kind in the repository is #158, which is a manual workflow_dispatch run I triggered on 2026-08-28 to test (see section 5). The newest Scheduled run is still #157.

Important: the run objects are not appearing in any state. There are no queued runs, no startup_failure runs, and no failed runs. The Actions UI simply shows nothing after #157. It is as if the cron trigger no longer exists for this repository.

---

3. Timeline (UTC)

UTC	Event
2026-08-26 15:11	GitHub incident "Incident with Actions" begins — impact: Critical (per GitHub Status)
2026-08-26 17:37	hourly-snapshot #157 runs and succeeds — last scheduled run ever created
2026-08-26 18:01	That incident is marked resolved
2026-08-26 18:23	First missed slot — 22 minutes after the incident was declared resolved. Scheduled runs never resume
2026-08-26 22:56	GitHub incident "Incident with Actions and Pull Requests" (Minor) begins → resolved 2026-08-27 00:26
2026-08-26 23:37	GitHub incident "Disruption with GitHub Billing" (Minor) begins
2026-08-27 04:17	daily-vods scheduled slot — missed
2026-08-27 ~01:48	Push to default branch main (attempt to force schedule re-registration) — no effect
2026-08-27 10:08	Repository renamed: shinkunda/HypeLog → shinkunda/my-virtual-company (see section 4)
2026-08-27 10:25 – 15:48	Four more pushes to main, including a comment-only change to hourly-snapshot.yml (commit 13a1b82) — no effect
—	Disable → Enable performed on the workflow in the Actions UI — no effect
2026-08-27 19:44	"Disruption with GitHub Billing" is marked resolved. GitHub Status returns to All Systems Operational
2026-08-28 01:19:18	Manual workflow_dispatch run #158 — SUCCESS (see section 5)
2026-08-28 ~01:35	Another comment-only change pushed to main (commit d361784) — this was the first re-registration attempt made while GitHub Status was fully Operational
2026-08-28 02:23	Next hourly slot after that push — still missed
2026-08-28 03:02	Current. Still no scheduled run. Latest Scheduled run remains #157

The correlation with the Critical Actions incident is exact: the last successful scheduled run happened during the incident window, and the first miss was 22 minutes after it was declared resolved. Scheduled runs have never recovered on their own.

---

4. About the repository rename

The repository was renamed from shinkunda/HypeLog to shinkunda/my-virtual-company at 2026-08-27 10:08 UTC (confirmed via the repo.rename entry in my account security log).

I want to be clear that this is not the initial cause: the schedule stopped at 2026-08-26 18:23 UTC, which is roughly 16 hours before the rename. I am mentioning it only because it is a server-side re-keying of the repository that happened in the middle of my recovery attempts, and it may be relevant to why re-registration is not taking effect.

---

5. The decisive diagnostic: manual dispatch works

To separate "this repository cannot create runs at all" from "only the cron scheduler is broken", I triggered a manual run.

Item	Value
Run	hourly-snapshot #158
Trigger	workflow_dispatch (manually triggered)
Branch / commit	main / 13a1b82
Started	2026-08-28 01:19:18 UTC
Result	✅ Success — job snapshot 53s, total 58s, 1 artifact
Job output	clips-incremental: events: 2, succeeded: 2, skipped: 0, failed: 0
Database write	Succeeded normally (production PostgreSQL / Neon)

Conclusion from this test: the Actions runners, the repository's Secrets, the database role and connectivity, and the workflow's own job logic are all working correctly. The only thing that is not working is the cron scheduler creating scheduled run objects.

---

6. What I have already ruled out

Checked	Result
Workflow files present on the default branch main	✅ Both present
YAML validity	✅ Both parse successfully. Top-level keys are name, on, concurrency, jobs
The on: key parsing as YAML 1.1 boolean true	✅ Not an issue — resolves correctly as on
on.schedule values	✅ [{cron: "23 * * * *"}] and [{cron: "17 4 * * *"}] — both valid
Tabs / CRLF / BOM in the workflow files	✅ None
Workflow enabled or disabled	✅ Both enabled. The Actions UI shows "Run workflow" and displays no "Enable workflow" banner
Repository-level Actions permissions	✅ Enabled — "Allow all actions and reusable workflows"
Actions minutes	✅ 182 / 2,000 minutes used. The counter has not moved, consistent with zero runs
Actions storage	✅ 0 GB / 0.5 GB
Billing / spending limit block	✅ None — billable usage $0, no overage
60-day inactivity auto-disable	✅ Not applicable — the repository has commits on the same day, and no inactivity banner is shown
Repository archived or deleted	✅ No — pushes are succeeding
GitHub Status	✅ All Systems Operational, no unresolved incidents

---

7. Recovery attempts already made — all ineffective

Attempt	Times	Result
Disable → Enable the workflow in the Actions UI	1	❌ No effect
Push a change to the workflow file on the default branch to force schedule re-registration (comment-only changes; workflow logic and cron values unchanged)	6	❌ No effect
— of which, pushed after GitHub Status returned to fully Operational (commit d361784, 2026-08-28)	1	❌ No effect — the following 02:23 UTC slot was still missed
Manual workflow_dispatch	1	✅ Succeeded — proving the failure is scheduler-specific

Note that the first five pushes all happened while the "Disruption with GitHub Billing" incident was still open, so I deliberately repeated the attempt on 2026-08-28 after GitHub Status was fully green. It made no difference.

---

8. Business impact

This is a data-collection service. The hourly workflow records Twitch clip view counts, and the Twitch API only returns the current value — there is no historical endpoint. Each snapshot bucket is derived from the execution time.

This means every missed hourly slot is permanently unrecoverable. I cannot backfill the gap after the fact. I am currently losing one irreplaceable data point every hour, and have already lost approximately 33 hours of continuous history.

---

9. What I am asking for

1. Could you check the server-side cron/schedule registration for shinkunda/my-virtual-company and confirm whether the schedules for hourly-snapshot and daily-vods still exist in GitHub's scheduler?
2. If the registration was lost (most likely during the 2026-08-26 Critical Actions incident, and/or not correctly migrated during the 2026-08-27 rename), could you re-create or re-trigger it on your side?
3. If there is any action I can take from the repository side that I have not already tried, please tell me — I have exhausted everything documented.

Thank you very much for your help.

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

[SirHegel]

This no longer looks specific to the repository rename, a private repository, or a Free account. There are now several independent reports with the same distinguishing symptom: workflow_dispatch creates a run, while schedule creates no run object at all.

• #205984: a new account, two unrelated repositories, and zero scheduled runs.
• #205999: an active workflow in a private repository, with push/PR runs still working.
• #206019: a public repository whose scheduled runs first became hours late and then disappeared.
• This report: two workflows, off-hour cron minutes, an active default branch, and a successful manual control run.

The timing also has a plausible platform-side mechanism. GitHub's August 26 Actions incident was attributed to saturation of the database primary used by the service that processes workflow triggers. The later Actions and Pull Requests incident reported that a subset of runs failed to trigger. That correlation supports—but does not prove—a residual scheduler registration or dispatch problem.

GitHub documents that scheduled events can be delayed or dropped during high load, particularly near the start of an hour. That does not adequately explain 33 consecutive misses at :23, after service recovery, while manual dispatch continues to work. The relevant documented behavior is under schedule.

You have already exhausted the repository-side refresh operations I would consider safe: confirm the workflow is active on the default branch, edit the workflow on that branch, and disable/re-enable it. The public workflow API exposes the workflow's state and lets an authorized caller dispatch it, but it does not expose an internal cron-registration record that a user can inspect or repair. At this point, GitHub staff need the repository ID and both workflow IDs to check that internal state. Your timeline and successful manual run are already an unusually strong evidence packet.

For the irreplaceable hourly samples, I would treat an external dispatch as a temporary continuity measure, not as a fix. From an already controlled, always-on machine, an hourly timer can invoke:

gh workflow run hourly-snapshot.yml \
  --repo shinkunda/my-virtual-company \
  --ref main

Use a fine-grained token limited to that single repository, with only the permission needed to run Actions, an expiry, and no token output in logs. Keep the workflow's existing idempotency/concurrency guard so a recovered native cron and the temporary dispatcher cannot double-write a bucket. Because your manual control already succeeds, this bypasses only the missing trigger-materialization step.

I would also link these reports together in any staff escalation. The cross-account/public-private pattern is the clearest evidence that the rename is not the sole cause.

Disclosure: Codex assisted with drafting this synthesis; I verified the linked GitHub status incidents, documentation, discussion timelines, and commands before posting.

[yidianstudio-netizen]

We are seeing the same issue on another private repository.

Repository: yidianstudio-netizen/marche-news-workbench

Workflow: W01 Scheduled News Production
Workflow ID: 330402367

Last successful scheduled run:
Run #143 / ID 33010271474, Aug 26, 2026.

Since then:

Aug 27: all four scheduled slots were missed.
Aug 28 08:30 Europe/Rome: no scheduled run object created.
Aug 28 12:30 Europe/Rome: no scheduled run object created.

Manual workflow_dispatch on the same workflow works correctly:

Run #147:
https://github.com/yidianstudio-netizen/marche-news-workbench/actions/runs/33120066192

Run #148:
https://github.com/yidianstudio-netizen/marche-news-workbench/actions/runs/33158913397

Run #148 completed the full production pipeline successfully.

We also tried:

Disable → Enable workflow
A real cron schedule change committed to the default branch
Updating the matching github.event.schedule stage mappings
Full CI/regression validation

PR #141:
https://github.com/yidianstudio-netizen/marche-news-workbench/pull/141

Current main commit:
847c8cb5b9e1afcc49a1e50902d4864f0dc9cf81

After re-registering the cron definitions, the Aug 28 12:30 slot was still missed.

The key symptom is identical: schedule creates no workflow run object at all, while workflow_dispatch works.

This appears to be a GitHub Actions scheduler/control-plane or server-side cron registration issue.

[guirguisb-stack]

Confirming the same scheduler/control-plane symptom in another private repository with four unrelated Production safeguard workflows.

• All four workflow files are valid on the default branch and their workflow state is active.
• Repository Actions permissions are enabled; fresh push and pull-request CI runs continue to start and pass.
• The last native scheduled runs were created on August 26 for the daily backup/watchdog and around 00:51–00:57 UTC on August 28 for the 5-minute and 15-minute monitors.
• Since then, schedule has created no run objects at all: not queued, skipped, startup-failed, or canceled.
• A disable → enable canary on the 5-minute workflow updated the workflow registration timestamp but multiple subsequent cron slots were still missed.
• Manual workflow_dispatch is functional, but it is not being treated as proof of schedule recovery.

No source, default-branch, workflow-state, repository-permission, or general Actions failure explains the cross-workflow stop. The timing overlaps the August 26 Actions trigger-processing incident, and the symptom matches the other reports here.

GitHub staff need to inspect or rebuild the server-side cron registrations. I can provide the private repository ID, four workflow IDs, and exact run URLs privately to GitHub staff; I am intentionally not posting private repository details publicly.

[emailtoalex]

Confirming the same issue in another independent private repository.
Repository: emailtoalex/epilepsie-monitoring
We have two independent workflows affected:
EPI-008 Push Scheduler — Workflow ID 344456806
Diagnostic Schedule Test — Workflow ID 344901227
The diagnostic workflow was created specifically to isolate the issue. It contains only a schedule trigger (*/5 * * * *) and a single echo command — no secrets, no external services, no Vercel/Supabase calls, and no application dependencies.
Result: zero scheduled run objects were created, despite multiple missed cron slots.
On the main workflow, workflow_dispatch works and successfully creates a run (Run ID 33190672892), while schedule never creates a run object.
We have also verified:
default branch is main
workflows are active
Actions are enabled
billing/minutes are not exhausted (1 / 2,000 minutes used)
cron syntax is valid
disable → enable did not recover scheduling
multiple scheduled slots were missed after re-enabling
This independently reproduces the same scheduler/control-plane symptom reported here: manual dispatch works, while schedule produces no run object at all.
No repository-side changes will be made for now. It would be helpful if GitHub staff could inspect the server-side cron registration / trigger-processing state for the affected workflow IDs.

[njzhx]

I’m seeing the same issue in a public repository. Multiple active scheduled workflows have stopped creating run records, while manual workflow_dispatch runs still work normally. The workflow files are present on the default branch, Actions permissions are enabled, and the self-hosted runners are online. There are no queued, failed, or cancelled runs for the missed cron times—the scheduled run objects simply aren’t being created. This appears to be a scheduler-side issue following the recent Actions incidents.

[shinkunda]

Hi Jhon, Just a quick update — the scheduled workflows have started running normally again. It looks like this really was a temporary GitHub-side issue. Thank you so much for taking the time to investigate this and for your detailed and kind response. It was really helpful! Thanks again! 2026年8月29日(土) 8:27 njzhx ***@***.***>:

…

I’m seeing the same issue in a public repository. Multiple active scheduled workflows have stopped creating run records, while manual workflow_dispatch runs still work normally. The workflow files are present on the default branch, Actions permissions are enabled, and the self-hosted runners are online. There are no queued, failed, or cancelled runs for the missed cron times—the scheduled run objects simply aren’t being created. This appears to be a scheduler-side issue following the recent Actions incidents. — Reply to this email directly, view it on GitHub <#206027?email_source=notifications&email_token=CK67JJG4TDP33X34C5RCVW35MIIMZA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBRHE2DGMRVUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-18194325>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CK67JJFKRQ7HGB32IXQCNTD5MIIMZAVCNFSNUABIKJSXA33TNF2G64TZHMZTAMJVG4ZTGNBUHNCGS43DOVZXG2LPNY5TCMBXGAZDCMJSUF3AE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[shinkunda]

Thanks everyone for your help.

The scheduled workflows have started running normally again, so it looks like this was indeed a temporary GitHub-side issue.

I really appreciate everyone who took the time to investigate, share information, and help me troubleshoot this. Thank you all so much!