Actions run stuck queued with zero jobs; cancel and force-cancel both return 409

[tonybesay]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Workflow Deployment

Discussion Details

An Actions workflow_dispatch run in a private repository has remained queued for over an hour, with no jobs created. I am looking for a safe way to get the inconsistent run cleared, or for the appropriate escalation route.

Observed facts:

• The workflow run REST endpoint reports status=queued, conclusion=null, run_attempt=1.
• The associated check suite also reports queued, with zero check runs.
• The run jobs endpoint reports total_count=0.
• There are no pending environment approvals, and no other active repository runs were found in our checks.
• Both the standard cancel endpoint and the force-cancel endpoint were called once for this same unstarted run. Both returned HTTP 409 with this exact message: "Cannot cancel a workflow run that has not been queued yet."
• No replacement dispatch or rerun has been requested.

Relevant timeline: the workflow had been manually disabled, was temporarily enabled for the single manual dispatch, then disabled again. A later temporary re-enable did not create any jobs; it is currently disabled again to prevent additional triggers. I do not know whether this timing contributed to the inconsistent state. The workflow uses a workflow-level concurrency group with cancel-in-progress: false. We have not changed that group or bypassed its protections.

The official troubleshooting page describes zero-job queued runs and cancellation HTTP 409 responses as potentially abnormal/out-of-sync, and says Support may be needed:
https://docs.github.com/en/actions/how-tos/troubleshoot-workflows#canceling-workflows

However, the support portal says technical support is not included in my current plan, and does not offer an Actions technical category.

Questions:

1. Is there any supported self-service action left that can conclusively cancel this specific unstarted run, without deleting history, changing concurrency, or launching another deployment?
2. If only GitHub can clear it, how should a Free account privately provide the affected run identifiers to the appropriate team?

I have searched for similar reports, including discussions about queued runs with zero jobs and cancel/force-cancel returning 409. I have deliberately omitted repository names, private URLs, run/check-suite IDs, commit hashes, credentials, and application data from this public post. Please advise on a private channel if identifiers are needed. I am not asking anyone to rerun or dispatch a workflow.

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

[foozy74]

Hi @tonybesay,
Since your private repository workflow is caught in an asynchronous state due to the rapid enable/disable toggle while a concurrency group was active, here are a few self-service workarounds that often force the GitHub backend to sync up and clear the stuck run:

1. Force-Cancel via GitHub CLI (gh)

Sometimes the web interface restriction fails to bypass the 409 error, but executing it directly via the GitHub CLI bypasses the front-end validation layer. If you have the CLI installed, try running:

gh run cancel <RUN_ID>

(Replace <RUN_ID> with the specific ID of the stuck queued workflow).

2. Bypass the Concurrency Lock

Since you mentioned a workflow-level concurrency group is active with cancel-in-progress: false, the backend is essentially locking itself out.

1. Temporarily change the name of the concurrency group in your workflow YAML file on your default branch (or temporarily comment out the concurrency block entirely).

2. Commit the change.

3. Re-enable the workflow.
   Often, changing the concurrency context breaks the internal database lock, allowing the system to naturally time out or clear the orphan queued run.

4. Contacting Support on a Free Plan

If the self-service steps do not clear it, this is a known edge-case backend desync that only GitHub Staff can manually purge.
Even on a Free tier plan, you can route this as an infrastructure bug rather than a technical assistance request:

1. Go to the GitHub Support Portal.
2. Select Report a bug or look for an Account/Platform Stability category.
3. In your ticket, explicitly mention that "a stuck workflow run in a private repository is permanently blocking infrastructure with a 409 error." This automatically flags it for the virtual infrastructure team to clear without requiring a paid support contract.
   Hope one of these helps you get it unstuck!

[andrii-matsuk]

I'm experiencing the exact same issue in my private repository.

Repository: andrii-matsuk/tier-list-project

Affected workflow runs:

• https://github.com/andrii-matsuk/tier-list-project/actions/runs/43095209184
• https://github.com/andrii-matsuk/tier-list-project/actions/runs/43095201216

Both runs have been stuck in the queued state since November 11, 2026, at approximately 20:18 UTC.

Symptoms:

• Both runs show queued, but the API returns jobs: [].
• Neither workflow starts executing.
• Regular cancellation doesn't work.
• The force-cancel API returns HTTP 409: Cannot cancel a workflow run that has not been queued yet.
• GitHub Actions usage is well below the included billing limit.
• Previous workflows in the same repository completed successfully.

This appears to be an issue with GitHub Actions scheduling rather than the workflow configuration.

Is GitHub aware of this issue, and is there an estimated time for a fix? Could someone from the GitHub team investigate and clear these stuck runs?

[Jeraling]

Same symptom on a different account and time window, with what rules out the usual self-service causes.

Window (all times UTC, 2026-11-11) — private repository, pull_request runs on one head:

Run	Workflow	Status
43095113024	CI	queued, created 20:17:32Z
43095112801	Secret scan	queued, created 20:17:32Z
43095112832	Skills docs-as-code lint	queued, created 20:17:32Z

At 20:45:52Z (28 minutes later) all three still reported status: queued, conclusion: null, with
run_started_at and updated_at still 20:17:32Z, and GET /actions/runs/{id}/jobs returned
total_count: 0 — no job object was ever created.

Cancellation is refused, four ways:

gh run cancel <id>                    -> "Cannot cancel a workflow run that is completed"
POST /actions/runs/{id}/cancel        -> 409 "Cannot cancel a workflow run that has not been queued yet."
POST /actions/runs/{id}/force-cancel  -> 409 "Cannot cancel a workflow run that has not been queued yet."

The two messages contradict each other and the status: queued the read endpoints return.

What is not the cause (checked, not assumed):

• githubstatus.com at the time: overall All Systems Operational, component Actions operational,
  0 unresolved incidents.
• Not a minutes or spending block: the account owner checked Billing in the browser — included minutes
  available, $0 billed.
• Repo Actions permissions: enabled: true, allowed_actions: all. The only queued runs in that repository
  are these three.
• The same repository had completed three green runs seven minutes earlier (20:10:45Z) on the previous
  head, so nothing about the account was blocked before 20:17.

And re-creating them does not help: closing and reopening the pull request (no new commits, identical
head) produced three new runs at 20:49:08Z, 43098259783 (CI), 43098259682 (Secret scan) and
43098259677 (Skills docs-as-code lint), and they queued the same way with zero jobs.

Happy to run any diagnostic you want against that repository while the stale runs are still there.

[aesharhel-bot]

Thanks for sharing such detailed diagnostics. I'm researching GitHub Actions reliability and how development teams monitor workflow failures.

How did you discover that these runs were stuck? Do you currently use any external monitoring tools, or do you manually check the GitHub Actions dashboard?

I'd really appreciate hearing about your experience.

[pjguti]

We can confirm a larger instance of this same symptom in a private repository on GitHub Free, without any workflow enable/disable toggles:

• 60 Actions runs created by five issue_comment events on November 11, 2026, between 20:21 and 20:42 UTC (12 workflows per comment).
• All 60 remain queued with zero jobs, no assigned runner and unchanged update timestamps.
• Each affected workflow's job-level condition would exclude the triggering issue; newer equivalent issue_comment runs now finish skipped normally.
• One sample run's check suite is also queued with zero check runs.
• Standard cancellation was rejected on seven runs. A single POST /actions/runs/{run_id}/force-cancel returned HTTP 409 Conflict on Nov 12 at 06:23:44 UTC, request ID 83F4:140046:18DCBA:2E4CEE:6AF55B6F. We stopped further requests instead of retrying, changing concurrency or deleting history.
• GitHub currently reports the repository runners online and idle; new runs can be evaluated, so this is not explained by runner exhaustion.

This began near the Nov 11 Actions incident, but we cannot establish causality. Can GitHub staff advise how to reconcile the orphaned workflow runs and check suites server-side, preserving audit history, and where a GitHub Free user can provide private identifiers securely? We have intentionally omitted the private repository name, local infrastructure and credentials.

A separate attempt to create our own Community discussion (#212851) was automatically closed because the forum requires the official UI template. We are adding this evidence to this existing UI-template discussion instead.

[hchahineuk-png]

Hello, I'm experiencing a very similar GitHub Actions problem.

A workflow in my private repository has remained QUEUED since 11 November 2026, with zero jobs created and no conclusion.

The run has not started, and I have avoided launching further workflows.

I have not confirmed whether cancellation returns HTTP 409, so I cannot claim the issue is identical.

My GitHub account does not offer an Actions technical-support category.

Could GitHub staff advise how to clear the stuck run or escalate it privately?

Thank you.

[hchahineuk-png]

Thank you for responding.

We discovered the problem by checking the GitHub Actions dashboard and verifying the run through GitHub's API.

The workflow remained QUEUED with zero jobs created, no conclusion and no progress.

We are not using a dedicated external monitoring service. We have been checking the workflow status through authorised GitHub tools and the dashboard.

Our main concern is finding a supported way to cancel or clear the stuck run without triggering duplicate workflows.

Do you know of an official escalation route for this issue on a personal GitHub account?

Thank you for your help.

[tonybesay]

Update — 12 November 2026. I have rechecked the affected run through the GitHub API:

• Workflow: Deploy Production
• Run ID: 42513767383
• Created at: 2026-11-08T19:11:17Z
• Updated at: 2026-11-08T19:11:17Z (unchanged)
• Status: queued
• Conclusion: empty
• Jobs: [] (zero jobs created)

This is currently the only queued run in the repository, and there are no in-progress runs. A later Spaces Minimal CI run (42975924785), created on 11 November, completed successfully, so Actions execution is not globally blocked for this repository.

I have not retried cancel/force-cancel during this latest read-only check; the previously reported HTTP 409 remains historical evidence, not a new test. No workflows were retriggered and no concurrency settings were changed during this check.

Could GitHub staff please investigate run 42513767383 and reconcile/clear its stuck server-side state while preserving the audit history? If private repository identifiers or additional diagnostics are required, please advise a secure escalation channel. I would prefer not to trigger duplicate deployments or bypass deployment concurrency protections. Thank you.

[aesharhel-bot]

Thanks for the detailed update. I'm researching GitHub Actions reliability issues. I'm curious: before this incident, had you experienced other runs getting stuck in the QUEUED state with zero jobs, or is this the first time? Also, how long did it take you to identify that the run was stuck? ‫في الخميس، 12 نوفمبر 2026 في 12:28 م تمت كتابة ما يلي بواسطة ‪Tony Mendoza Hernandez‬‏ ***@***.***‬‏>:‬

…

Update — 12 November 2026. I have rechecked the affected run through the GitHub API: - Workflow: Deploy Production - Run ID: 42513767383 - Created at: 2026-11-08T19:11:17Z - Updated at: 2026-11-08T19:11:17Z (unchanged) - Status: queued - Conclusion: empty - Jobs: [] (zero jobs created) This is currently the only queued run in the repository, and there are no in-progress runs. A later Spaces Minimal CI run (42975924785), created on 11 November, completed successfully, so Actions execution is not globally blocked for this repository. I have not retried cancel/force-cancel during this latest read-only check; the previously reported HTTP 409 remains historical evidence, not a new test. No workflows were retriggered and no concurrency settings were changed during this check. Could GitHub staff please investigate run 42513767383 and reconcile/clear its stuck server-side state while preserving the audit history? If private repository identifiers or additional diagnostics are required, please advise a secure escalation channel. I would prefer not to trigger duplicate deployments or bypass deployment concurrency protections. Thank you. — Reply to this email directly, view it on GitHub <#212468?email_source=notifications&email_token=CUSS3KCDEMIEJTLSVBZWHBD5YWGF5A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOJVGYZDCOBTUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-19562183>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CUSS3KCQC6UZFAEV6773LMT5YWGF5AVCNFSNUABIKJSXA33TNF2G64TZHMZTAMJVG4ZTGNBUHNCGS43DOVZXG2LPNY5TCMJSGU4DEMBRUF3AE> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/CUSS3KBBKF6ZXFVP3QMO7SD5YWGF5A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOJVGYZDCOBTUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSVGM33PORSXEX3JN5ZQ> and Android <https://github.com/notifications/mobile/android/CUSS3KCCD27E6KRF2G3HPOD5YWGF5A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOJVGYZDCOBTUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ>. Download it today! You are receiving this because you commented.Message ID: ***@***.***>

[aesharhel-bot]

Thanks for explaining the situation. The detail about checking both the dashboard and API is particularly useful. I can see why this is frustrating, especially when a stuck run cannot be safely cancelled or retried without risking duplicate workflows. One thing I find interesting is the lack of visibility into what action is safe to take next. Detecting a queued run is one thing, but understanding whether it is waiting for a runner, stuck with zero jobs, or affected by a platform-side issue is much more valuable. I'm exploring the idea of a monitoring tool that could detect these states, track how long runs remain stuck, and provide context-aware recovery guidance without automatically triggering duplicate runs. I agree that this would be particularly useful for teams managing multiple repositories. Thanks again for sharing your experience! ‫في الخميس، 12 نوفمبر 2026 في 12:12 م تمت كتابة ما يلي بواسطة ‪hchahineuk-png‬‏ ***@***.***‬‏>:‬

…

Thank you for responding. We discovered the problem by checking the GitHub Actions dashboard and verifying the run through GitHub's API. The workflow remained QUEUED with zero jobs created, no conclusion and no progress. We are not using a dedicated external monitoring service. We have been checking the workflow status through authorised GitHub tools and the dashboard. Our main concern is finding a supported way to cancel or clear the stuck run without triggering duplicate workflows. Do you know of an official escalation route for this issue on a personal GitHub account? Thank you for your help. — Reply to this email directly, view it on GitHub <#212468?email_source=notifications&email_token=CUSS3KAIF7W54V2PZ2NRCPD5YWEHDA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOJVGYYTQNJXUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-19561857>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CUSS3KFEFKTKUNFCSZOSV6L5YWEHDAVCNFSNUABIKJSXA33TNF2G64TZHMZTAMJVG4ZTGNBUHNCGS43DOVZXG2LPNY5TCMJSGU4DEMBRUF3AE> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/CUSS3KE5F3TS6OYW6XKJRO35YWEHDA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOJVGYYTQNJXUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSVGM33PORSXEX3JN5ZQ> and Android <https://github.com/notifications/mobile/android/CUSS3KCEQROCD6EHSQHBTPD5YWEHDA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOJVGYYTQNJXUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ>. Download it today! You are receiving this because you commented.Message ID: ***@***.***>

[aesharhel-bot]

Thanks for the detailed update. I think the comparison with the later successful run is particularly useful. It shows why monitoring only the overall repository or runner status can be misleading. Actions can continue executing new workflows while an individual run remains stuck with no jobs created and no state updates. I also think your decision to avoid retrying or changing concurrency settings without understanding the underlying state is important, especially for production deployments. This is exactly the kind of situation where run-level monitoring, historical state tracking, and clear recovery guidance could help engineering teams avoid unnecessary risks. Appreciate you documenting the API evidence so carefully. ‫في الخميس، 12 نوفمبر 2026 في 12:28 م تمت كتابة ما يلي بواسطة ‪Tony Mendoza Hernandez‬‏ ***@***.***‬‏>:‬

…

Update — 12 November 2026. I have rechecked the affected run through the GitHub API: - Workflow: Deploy Production - Run ID: 42513767383 - Created at: 2026-11-08T19:11:17Z - Updated at: 2026-11-08T19:11:17Z (unchanged) - Status: queued - Conclusion: empty - Jobs: [] (zero jobs created) This is currently the only queued run in the repository, and there are no in-progress runs. A later Spaces Minimal CI run (42975924785), created on 11 November, completed successfully, so Actions execution is not globally blocked for this repository. I have not retried cancel/force-cancel during this latest read-only check; the previously reported HTTP 409 remains historical evidence, not a new test. No workflows were retriggered and no concurrency settings were changed during this check. Could GitHub staff please investigate run 42513767383 and reconcile/clear its stuck server-side state while preserving the audit history? If private repository identifiers or additional diagnostics are required, please advise a secure escalation channel. I would prefer not to trigger duplicate deployments or bypass deployment concurrency protections. Thank you. — Reply to this email directly, view it on GitHub <#212468?email_source=notifications&email_token=CUSS3KCDEMIEJTLSVBZWHBD5YWGF5A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOJVGYZDCOBTUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-19562183>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CUSS3KCQC6UZFAEV6773LMT5YWGF5AVCNFSNUABIKJSXA33TNF2G64TZHMZTAMJVG4ZTGNBUHNCGS43DOVZXG2LPNY5TCMJSGU4DEMBRUF3AE> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/CUSS3KBBKF6ZXFVP3QMO7SD5YWGF5A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOJVGYZDCOBTUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSVGM33PORSXEX3JN5ZQ> and Android <https://github.com/notifications/mobile/android/CUSS3KCCD27E6KRF2G3HPOD5YWGF5A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOJVGYZDCOBTUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ>. Download it today! You are receiving this because you commented.Message ID: ***@***.***>

[herculesbroken11]

I'm experiencing the same GitHub Actions issue in a private repository.

Affected workflow details:

• Workflow: CI
• Branch: develop
• Event: Workflow execution triggered by a commit
• Affected run: November 11, 2026

Observed behavior:

1. The workflow remains permanently in queued status.

2. No jobs are created. The workflow jobs API returns total_count: 0.

3. The associated Check Suite also remains queued with zero check runs.

4. Running gh run cancel returns:

   Cannot cancel a workflow run that is completed

5. Attempting force cancellation returns HTTP 409:

   Cannot cancel a workflow run that has not been queued yet.

6. Attempting to re-request the Check Suite using:

   gh api --method POST repos///check-suites/<check_suite_id>/rerequest

   returns HTTP 404:

   Not Found

Troubleshooting already completed:

• Reviewed the workflow YAML configuration.
• actionlint 1.7.12 passes without findings.
• All four jobs use ubuntu-latest.
• No other queued or in-progress workflow runs were found.
• The workflow configuration has not been changed as part of troubleshooting.

The behavior appears consistent with an inconsistent GitHub Actions workflow-run/check-suite scheduling state rather than a normal runner execution failure.

Questions for the GitHub Actions team:

1. Is this a known GitHub Actions scheduling or backend state inconsistency?
2. Is there a supported way to clear or recover this workflow run without modifying application code or bypassing required CI checks?
3. Can GitHub investigate and reconcile the affected workflow run and its associated Check Suite server-side?
4. Is there a recommended recovery procedure for users who cannot access technical support directly?

The repository is private, so I have intentionally omitted its name, run URL, commit SHA, and identifiers from this public comment. I can provide the exact run ID, Check Suite ID, and additional diagnostic information privately if needed.

I would appreciate any guidance or assistance from the GitHub Actions team. Thank you.

[ExpoProffsenter]

We also need help investigating stuck GitHub Actions runs in:
https://github.com/ExpoProffsenter/expo-proffdok

The workflow is PR Core Safety (.github/workflows/pr-core-safety.yml). Six runs have remained queued since November 11, 2026, with no jobs created. This is blocking our release verification.

The two release-related runs are:

• PR #322: Release: godkjent supportmodus – ny testkø for uendret kandidat ExpoProffsenter/expo-proffdok#322
  Run: https://github.com/ExpoProffsenter/expo-proffdok/actions/runs/43097898264
  Commit: be48b7978a1d3bb4cd9d43e8938f67a25e9f661e

• PR #320: Bolig: kundebundet support for kontraktfiler ExpoProffsenter/expo-proffdok#320
  Run: https://github.com/ExpoProffsenter/expo-proffdok/actions/runs/43097043078
  Commit: 007364a4957a738f5b215b450060618c32befb42

Troubleshooting performed:

• Normal cancellation in the GitHub UI failed.
• Force-cancelling older run 43095151308 returned HTTP 409: “Cannot cancel a workflow run that has not been queued yet.”
• Reading that same run returned status: "queued", an empty conclusion and jobs: [].
• Deleting that run using both GitHub CLI and the REST API returned HTTP 403: “Could not delete the workflow run.”
• The authenticated account has repository admin permissions. The CLI token has repo and workflow scopes.
• We disabled and re-enabled the workflow once on November 12. GitHub confirmed successful reactivation, but the runs remained queued.

Could you investigate the inconsistent run state, identify what is preventing jobs from starting, and help restore normal processing?

Please preserve the run history where possible. We have not bypassed the required checks or deployed the affected release.

Best regards,
Kenneth Skogsrud
ExpoProffsenter

[aesharhel-bot]

This is a particularly interesting case because the inconsistency affects both the workflow run and its associated Check Suite. What's concerning is that the workflow remains queued without creating any jobs, while the cancellation and re-request operations return conflicting errors. This makes it difficult for teams to know whether they should wait, retry, or escalate the issue — especially when required CI checks are involved. I think monitoring these states together could be useful, rather than simply checking whether a workflow is queued or failed. I'm researching a tool focused on GitHub Actions cost and reliability intelligence, particularly detecting abnormal workflow states and explaining what might be happening. I'm curious about one thing: *When this happens, what is the actual impact on your development workflow? Does it delay deployments or block your team from merging changes, and how much time do you usually spend investigating it?* Thanks for documenting the issue so clearly. ‫في الخميس، 12 نوفمبر 2026 في 4:33 م تمت كتابة ما يلي بواسطة ‪Hercules Schonfeldt‬‏ ***@***.***‬‏>:‬

…

I'm experiencing the same GitHub Actions issue in a private repository. Affected workflow details: - Workflow: CI - Branch: develop - Event: Workflow execution triggered by a commit - Affected run: November 11, 2026 Observed behavior: 1. The workflow remains permanently in queued status. 2. No jobs are created. The workflow jobs API returns total_count: 0. 3. The associated Check Suite also remains queued with zero check runs. 4. Running gh run cancel returns: Cannot cancel a workflow run that is completed 5. Attempting force cancellation returns HTTP 409: Cannot cancel a workflow run that has not been queued yet. 6. Attempting to re-request the Check Suite using: gh api --method POST repos///check-suites/<check_suite_id>/rerequest returns HTTP 404: Not Found Troubleshooting already completed: - Reviewed the workflow YAML configuration. - actionlint 1.7.12 passes without findings. - All four jobs use ubuntu-latest. - No other queued or in-progress workflow runs were found. - The workflow configuration has not been changed as part of troubleshooting. The behavior appears consistent with an inconsistent GitHub Actions workflow-run/check-suite scheduling state rather than a normal runner execution failure. Questions for the GitHub Actions team: 1. Is this a known GitHub Actions scheduling or backend state inconsistency? 2. Is there a supported way to clear or recover this workflow run without modifying application code or bypassing required CI checks? 3. Can GitHub investigate and reconcile the affected workflow run and its associated Check Suite server-side? 4. Is there a recommended recovery procedure for users who cannot access technical support directly? The repository is private, so I have intentionally omitted its name, run URL, commit SHA, and identifiers from this public comment. I can provide the exact run ID, Check Suite ID, and additional diagnostic information privately if needed. I would appreciate any guidance or assistance from the GitHub Actions team. Thank you. — Reply to this email directly, view it on GitHub <#212468?email_source=notifications&email_token=CUSS3KE4GCFQJOUDEABVRHT5YXC27A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOJVGY3DMNRWUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-19566666>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CUSS3KGWHPXTZ6PQV5E3PBD5YXC27AVCNFSNUABIKJSXA33TNF2G64TZHMZTAMJVG4ZTGNBUHNCGS43DOVZXG2LPNY5TCMJSGU4DEMBRUF3AE> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/CUSS3KFCZUFINNA5EW5VQAL5YXC27A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOJVGY3DMNRWUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSVGM33PORSXEX3JN5ZQ> and Android <https://github.com/notifications/mobile/android/CUSS3KGGYLE4FWSUJLKDYJT5YXC27A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOJVGY3DMNRWUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ>. Download it today! You are receiving this because you commented.Message ID: ***@***.***>

[herculesbroken11]

Thanks for your response.

In my case, this issue affects our development workflow because GitHub Actions is responsible for validating changes before we proceed with further development and deployment.

The affected CI run was triggered by a push to our develop branch after merging PR #160. It has remained queued without creating a single job.

The main impacts are:

• Delayed CI validation: We cannot confirm that the latest changes have passed the automated test pipeline.
• Deployment uncertainty: We cannot confidently proceed with any deployment process that depends on successful CI execution.
• Potential merge restrictions: If the affected check is required by branch protection, subsequent PRs could also be blocked.
• Investigation time: I've already spent several hours investigating the issue through GitHub CLI and REST API calls, trying cancellation, force cancellation, and Check Suite re-request operations. None of these approaches worked.

What makes this particularly concerning is that GitHub reports contradictory states: the workflow appears queued through the API, while cancellation reports that it is completed, and force cancellation returns HTTP 409.

I agree that monitoring workflow runs and their associated Check Suites together would be valuable. Detecting these abnormal states early, identifying whether the problem is related to scheduling or backend infrastructure, and providing a reliable recovery path would save developers considerable time.

My biggest concern is not simply detecting a stuck workflow, but having a supported way to recover it without disrupting the repository or compromising CI reliability.

Thanks for looking into this.

[aesharhel-bot]

Hi Kenneth, Thanks for sharing these additional details. This is a particularly useful example because it shows the operational impact of stuck workflow runs, not just the technical symptoms. What's especially concerning is that six runs remain queued with no jobs, and even repository admin permissions aren't enough to cancel or delete the affected runs. Disabling and re-enabling the workflow also didn't restore processing. The release verification impact is an important distinction. A monitoring tool that detects queued runs with zero jobs, tracks how long they remain stuck, and alerts the team before release verification is blocked could be valuable. I'm researching a product focused on GitHub Actions Cost & Reliability Intelligence, so real-world experiences like yours are very helpful. *I'm curious: how are you currently handling release verification while these runs are stuck? Do you have another monitoring or CI/CD tool that helps your team detect and investigate these issues, or are you relying mainly on GitHub's dashboard and API?* Thanks again for documenting the troubleshooting steps so thoroughly. ‫في الخميس، 12 نوفمبر 2026 في 4:37 م تمت كتابة ما يلي بواسطة ‪ExpoProffsenter‬‏ ***@***.***‬‏>:‬

…

We also need help investigating stuck GitHub Actions runs in: https://github.com/ExpoProffsenter/expo-proffdok The workflow is *PR Core Safety* (.github/workflows/pr-core-safety.yml). Six runs have remained queued since November 11, 2026, with no jobs created. This is blocking our release verification. The two release-related runs are: - PR #322: ExpoProffsenter/expo-proffdok#322 <ExpoProffsenter/expo-proffdok#322> Run: https://github.com/ExpoProffsenter/expo-proffdok/actions/runs/43097898264 Commit: be48b7978a1d3bb4cd9d43e8938f67a25e9f661e - PR #320: ExpoProffsenter/expo-proffdok#320 <ExpoProffsenter/expo-proffdok#320> Run: https://github.com/ExpoProffsenter/expo-proffdok/actions/runs/43097043078 Commit: 007364a4957a738f5b215b450060618c32befb42 Troubleshooting performed: - Normal cancellation in the GitHub UI failed. - Force-cancelling older run 43095151308 returned HTTP 409: “Cannot cancel a workflow run that has not been queued yet.” - Reading that same run returned status: "queued", an empty conclusion and jobs: []. - Deleting that run using both GitHub CLI and the REST API returned HTTP 403: “Could not delete the workflow run.” - The authenticated account has repository admin permissions. The CLI token has repo and workflow scopes. - We disabled and re-enabled the workflow once on November 12. GitHub confirmed successful reactivation, but the runs remained queued. Could you investigate the inconsistent run state, identify what is preventing jobs from starting, and help restore normal processing? Please preserve the run history where possible. We have not bypassed the required checks or deployed the affected release. Best regards, Kenneth Skogsrud ExpoProffsenter — Reply to this email directly, view it on GitHub <#212468?email_source=notifications&email_token=CUSS3KBKXMARZYU6SOAQGM35YXDJRA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOJVGY3DONJSUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-19566752>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CUSS3KGPZQJX23X35XC27DT5YXDJRAVCNFSNUABIKJSXA33TNF2G64TZHMZTAMJVG4ZTGNBUHNCGS43DOVZXG2LPNY5TCMJSGU4DEMBRUF3AE> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/CUSS3KFFAEXUZLQRF2JPNUT5YXDJRA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOJVGY3DONJSUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSVGM33PORSXEX3JN5ZQ> and Android <https://github.com/notifications/mobile/android/CUSS3KB4QLCD7QZYZJPL3AD5YXDJRA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOJVGY3DONJSUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ>. Download it today! You are receiving this because you commented.Message ID: ***@***.***>

[LHE2LAXAdmin]

We're experiencing the same issue in a private repository on GitHub Free.

Our staging diagnostic workflow has remained queued for approximately 18+ hours with no jobs started. Attempting to cancel it through the GitHub Actions UI produces "Failed to cancel workflow."

The workflow previously executed successfully, and the affected run was created around the November 11 Actions incident.

We've deliberately avoided rerunning, redispatching, changing concurrency configuration, or modifying the workflow to force execution. This diagnostic is part of a larger development workflow, so preserving execution history and avoiding duplicate runs is important.

GitHub's support portal does not offer an Actions technical-support category for our account.

Could GitHub staff confirm whether these orphaned queued runs are being investigated and provide a supported recovery or private escalation channel?

We can supply the affected repository and workflow-run identifiers privately if needed.

[aesharhel-bot]

Thanks for explaining the impact in detail. The several hours spent investigating this issue are particularly important. I have one follow-up question: Has your team experienced similar stuck workflow or Check Suite issues before, or is this the first time? And if it has happened before, how frequently does it occur? I'm trying to understand whether this is an occasional incident or a recurring reliability problem for engineering teams. Thanks again for sharing your experience. ‫في الخميس، 12 نوفمبر 2026 في 5:05 م تمت كتابة ما يلي بواسطة ‪Hercules Schonfeldt‬‏ ***@***.***‬‏>:‬

…

Thanks for your response. In my case, this issue affects our development workflow because GitHub Actions is responsible for validating changes before we proceed with further development and deployment. The affected CI run was triggered by a push to our develop branch after merging PR #160. It has remained queued without creating a single job. The main impacts are: - *Delayed CI validation:* We cannot confirm that the latest changes have passed the automated test pipeline. - *Deployment uncertainty:* We cannot confidently proceed with any deployment process that depends on successful CI execution. - *Potential merge restrictions:* If the affected check is required by branch protection, subsequent PRs could also be blocked. - *Investigation time:* I've already spent several hours investigating the issue through GitHub CLI and REST API calls, trying cancellation, force cancellation, and Check Suite re-request operations. None of these approaches worked. What makes this particularly concerning is that GitHub reports contradictory states: the workflow appears queued through the API, while cancellation reports that it is completed, and force cancellation returns HTTP 409. I agree that monitoring workflow runs and their associated Check Suites together would be valuable. Detecting these abnormal states early, identifying whether the problem is related to scheduling or backend infrastructure, and providing a reliable recovery path would save developers considerable time. My biggest concern is not simply detecting a stuck workflow, but having a supported way to recover it without disrupting the repository or compromising CI reliability. Thanks for looking into this. — Reply to this email directly, view it on GitHub <#212468?email_source=notifications&email_token=CUSS3KENJ4TM2PDB6F5N2GT5YXGUVA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOJVGY3TIMZYUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-19567438>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CUSS3KFJ5YEAITXQXRY2OWL5YXGUVAVCNFSNUABIKJSXA33TNF2G64TZHMZTAMJVG4ZTGNBUHNCGS43DOVZXG2LPNY5TCMJSGU4DEMBRUF3AE> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/CUSS3KF63CWGNTBIBRHASET5YXGUVA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOJVGY3TIMZYUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSVGM33PORSXEX3JN5ZQ> and Android <https://github.com/notifications/mobile/android/CUSS3KAOXINS4TYSSTDJAFT5YXGUVA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOJVGY3TIMZYUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ>. Download it today! You are receiving this because you commented.Message ID: ***@***.***>

[aesharhel-bot]

Thanks for sharing this. The fact that the workflow has remained queued for 18+ hours without creating jobs, while cancellation also fails, is particularly concerning. I have two questions: 1. How are you currently detecting and tracking these stuck runs? Are you relying entirely on GitHub's dashboard and API, or do you use an external monitoring tool? 2. Has this issue delayed any staging validation, testing, or deployment work for your team? I'm researching ways to help engineering teams detect and investigate GitHub Actions reliability issues without triggering unsafe duplicate runs. Thanks again for documenting this. ‫في الخميس، 12 نوفمبر 2026 في 5:14 م تمت كتابة ما يلي بواسطة ‪LHE2LAXAdmin‬‏ ***@***.***‬‏>:‬

…

We're experiencing the same issue in a private repository on GitHub Free. Our staging diagnostic workflow has remained *queued for approximately 18+ hours with no jobs started*. Attempting to cancel it through the GitHub Actions UI produces *"Failed to cancel workflow."* The workflow previously executed successfully, and the affected run was created around the November 11 Actions incident. We've deliberately avoided rerunning, redispatching, changing concurrency configuration, or modifying the workflow to force execution. This diagnostic is part of a larger development workflow, so preserving execution history and avoiding duplicate runs is important. GitHub's support portal does not offer an Actions technical-support category for our account. Could GitHub staff confirm whether these orphaned queued runs are being investigated and provide a supported recovery or private escalation channel? We can supply the affected repository and workflow-run identifiers privately if needed. — Reply to this email directly, view it on GitHub <#212468?email_source=notifications&email_token=CUSS3KFER662QCFIY4PJWIT5YXHUPA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOJVGY3TMMJYUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-19567618>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CUSS3KDYF75WMKIHVZEYPHD5YXHUPAVCNFSNUABIKJSXA33TNF2G64TZHMZTAMJVG4ZTGNBUHNCGS43DOVZXG2LPNY5TCMJSGU4DEMBRUF3AE> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/CUSS3KBTNALQQ663OMG6OZL5YXHUPA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOJVGY3TMMJYUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSVGM33PORSXEX3JN5ZQ> and Android <https://github.com/notifications/mobile/android/CUSS3KAQSVWSEHLF435ZA3D5YXHUPA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOJVGY3TMMJYUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ>. Download it today! You are receiving this because you commented.Message ID: ***@***.***>

[LHE2LAXAdmin]

We're currently monitoring the affected run through GitHub's Actions dashboard. We haven't deployed a separate monitoring service.

Yes, this has delayed our staging validation. The blocked workflow is a read-only diagnostic that we need to complete before resuming an authenticated publishing pipeline.

Our main concern is that the run remains queued without starting any jobs, while GitHub's cancellation mechanism also fails. We want to avoid creating unnecessary duplicate executions or altering workflow concurrency settings just to work around an inconsistent backend state.

If you're aware of an officially supported recovery procedure or a way to escalate an orphaned workflow to GitHub engineering, that would be particularly helpful.

[aesharhel-bot]

Thanks for clarifying. The impact on your staging validation and authenticated publishing pipeline is particularly important. I understand why you want to avoid duplicate executions or changing concurrency settings without knowing the underlying cause. One final question: Has your team experienced similar GitHub Actions incidents before, and approximately how much engineering time has this particular incident cost your team so far? I'm trying to understand how frequently these reliability issues occur and how much operational impact they create. I appreciate your detailed responses. ‫في الخميس، 12 نوفمبر 2026 في 5:48 م تمت كتابة ما يلي بواسطة ‪LHE2LAXAdmin‬‏ ***@***.***‬‏>:‬

…

We're currently monitoring the affected run through GitHub's Actions dashboard. We haven't deployed a separate monitoring service. Yes, this has delayed our staging validation. The blocked workflow is a read-only diagnostic that we need to complete before resuming an authenticated publishing pipeline. Our main concern is that the run remains queued without starting any jobs, while GitHub's cancellation mechanism also fails. We want to avoid creating unnecessary duplicate executions or altering workflow concurrency settings just to work around an inconsistent backend state. If you're aware of an officially supported recovery procedure or a way to escalate an orphaned workflow to GitHub engineering, that would be particularly helpful. — Reply to this email directly, view it on GitHub <#212468?email_source=notifications&email_token=CUSS3KDXTWE3G7QMJKNGWBT5YXLVTA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOJVGY4DIMRXUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-19568427>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CUSS3KF27TBEQJFSDMNRFMT5YXLVTAVCNFSNUABIKJSXA33TNF2G64TZHMZTAMJVG4ZTGNBUHNCGS43DOVZXG2LPNY5TCMJSGU4DEMBRUF3AE> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/CUSS3KFD4PEOS5Z2UVPN4WL5YXLVTA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOJVGY4DIMRXUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSVGM33PORSXEX3JN5ZQ> and Android <https://github.com/notifications/mobile/android/CUSS3KFXZYXV7BSHSEO2S6D5YXLVTA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOJVGY4DIMRXUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ>. Download it today! You are receiving this because you commented.Message ID: ***@***.***>

[aesharhel-bot]

One more question: Does your team currently pay for any CI/CD monitoring or observability tools? If a dedicated tool could detect these stuck runs, correlate workflow and Check Suite states, and provide safe recovery guidance, would your team consider paying for it? What would it need to demonstrate to justify the cost? ‫في الخميس، 12 نوفمبر 2026 في 5:48 م تمت كتابة ما يلي بواسطة ‪LHE2LAXAdmin‬‏ ***@***.***‬‏>:‬

…

We're currently monitoring the affected run through GitHub's Actions dashboard. We haven't deployed a separate monitoring service. Yes, this has delayed our staging validation. The blocked workflow is a read-only diagnostic that we need to complete before resuming an authenticated publishing pipeline. Our main concern is that the run remains queued without starting any jobs, while GitHub's cancellation mechanism also fails. We want to avoid creating unnecessary duplicate executions or altering workflow concurrency settings just to work around an inconsistent backend state. If you're aware of an officially supported recovery procedure or a way to escalate an orphaned workflow to GitHub engineering, that would be particularly helpful. — Reply to this email directly, view it on GitHub <#212468?email_source=notifications&email_token=CUSS3KDXTWE3G7QMJKNGWBT5YXLVTA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOJVGY4DIMRXUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-19568427>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CUSS3KF27TBEQJFSDMNRFMT5YXLVTAVCNFSNUABIKJSXA33TNF2G64TZHMZTAMJVG4ZTGNBUHNCGS43DOVZXG2LPNY5TCMJSGU4DEMBRUF3AE> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/CUSS3KFD4PEOS5Z2UVPN4WL5YXLVTA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOJVGY4DIMRXUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSVGM33PORSXEX3JN5ZQ> and Android <https://github.com/notifications/mobile/android/CUSS3KFXZYXV7BSHSEO2S6D5YXLVTA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOJVGY4DIMRXUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ>. Download it today! You are receiving this because you commented.Message ID: ***@***.***>

[bdavc]

I am experiencing the same issue with a private repository on November 11, 2026, at 20:18 UTC.

The workflow remains queued, with zero jobs created. My self-hosted Windows runner is online and idle, including after a restart.

Cancellation through the GitHub UI fails, and the force-cancel API returns HTTP 409: "Cannot cancel a workflow run that has not been queued yet."

GitHub Support automatically closed my ticket because my account only has access to self-service support resources.

Has anyone found a reliable recovery procedure that does not bypass concurrency safeguards or risk duplicate executions? Is there a way to escalate this infrastructure issue to GitHub staff?

[aesharhel-bot]

Hi! I'm currently researching how engineering teams use GitHub Actions, particularly around CI/CD costs, wasted workflow runs, and reliability issues. I'd really appreciate your perspective on a few questions: 1. What is the biggest challenge your team faces when using GitHub Actions? 2. How often do you experience unexpected CI costs, wasted workflow runs, or workflow reliability issues? 3. Can you describe the last time one of these problems occurred and how much time or money it cost your team? 4. How does your team currently monitor GitHub Actions costs, identify wasted CI minutes, and detect workflow failures? Do you use any paid tools? 5. If a tool could identify unnecessary workflow usage, explain cost increases, and detect reliability issues early, would your company consider paying for it? Why or why not? 6. What monthly price would your company realistically consider for a tool like this? Would your team be willing to test an early prototype? Your honest feedback would be extremely valuable to my research, even if your answer is that your team doesn't need such a tool. Thank you for your time! ‫في الخميس، 12 نوفمبر 2026 في 7:50 م تمت كتابة ما يلي بواسطة ‪bdavc‬‏ <‪ ***@***.***‬‏>:‬

…

I am experiencing the same issue with a private repository on November 11, 2026, at 20:18 UTC. The workflow remains queued, with zero jobs created. My self-hosted Windows runner is online and idle, including after a restart. Cancellation through the GitHub UI fails, and the force-cancel API returns HTTP 409: "Cannot cancel a workflow run that has not been queued yet." GitHub Support automatically closed my ticket because my account only has access to self-service support resources. Has anyone found a reliable recovery procedure that does not bypass concurrency safeguards or risk duplicate executions? Is there a way to escalate this infrastructure issue to GitHub staff? — Reply to this email directly, view it on GitHub <#212468?email_source=notifications&email_token=CUSS3KAV2OKYITNCYJ56NQD5YXZ5JA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOJVG4YTIMZWUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-19571436>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CUSS3KAODOXFDNTHWKICHVL5YXZ5JAVCNFSNUABIKJSXA33TNF2G64TZHMZTAMJVG4ZTGNBUHNCGS43DOVZXG2LPNY5TCMJSGU4DEMBRUF3AE> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/CUSS3KHCISKNJXW43A2HOSL5YXZ5JA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOJVG4YTIMZWUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSVGM33PORSXEX3JN5ZQ> and Android <https://github.com/notifications/mobile/android/CUSS3KHYQ2LIIQ6U2NFG6VD5YXZ5JA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOJVG4YTIMZWUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ>. Download it today! You are receiving this because you commented.Message ID: ***@***.***>

[mmarinhomac]

Same symptom, private repo, GitHub Free. Two push runs created Nov 11 ~20:25 UTC are stuck queued with zero jobs: 43096300331, 43096032331. force-cancel returns 409 "has not been queued yet", gh run delete returns 403. Could staff reconcile them server-side?

[aesharhel-bot]

Thanks for sharing these details. I'm researching GitHub Actions reliability issues. I'm curious: Have these stuck runs caused any delays to development, testing, or deployments? Did your team spend time investigating the runner configuration or troubleshooting the issue? Also, do new workflow runs work normally, or are they affected too? Thanks for sharing your experience! ‫في الخميس، 12 نوفمبر 2026 في 8:33 م تمت كتابة ما يلي بواسطة ‪Matheus Marinho‬‏ ***@***.***‬‏>:‬

…

Same symptom, private repo, GitHub Free. Two push runs created Nov 11 ~20:25 UTC are stuck queued with zero jobs: 43096300331, 43096032331. force-cancel returns 409 "has not been queued yet", gh run delete returns 403. Could staff reconcile them server-side? — Reply to this email directly, view it on GitHub <#212468?email_source=notifications&email_token=CUSS3KE23KNWVRHJXWW3BDL5YX653A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOJVG4ZDCMBQUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-19572100>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CUSS3KHTABXBCOAWPGQJQUD5YX653AVCNFSNUABIKJSXA33TNF2G64TZHMZTAMJVG4ZTGNBUHNCGS43DOVZXG2LPNY5TCMJSGU4DEMBRUF3AE> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/CUSS3KHEQZWVLLQ2SOYWLQT5YX653A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOJVG4ZDCMBQUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSVGM33PORSXEX3JN5ZQ> and Android <https://github.com/notifications/mobile/android/CUSS3KANLFE5IGKQPD3NYM35YX653A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOJVG4ZDCMBQUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ>. Download it today! You are receiving this because you commented.Message ID: ***@***.***>