GitHub Actions workflows stuck in Queued state and cannot be canceled after November 11 outage

[stephentaghan-a11y]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Other

Discussion Details

On November 11, 2026, three GitHub Actions workflow runs triggered by a draft pull request became stuck in the Queued state at approximately 2:53 PM Central.

Affected workflows:

• Foundation CI
• Dependency Review
• CodeQL

The previous Foundation CI completed successfully.

The queued runs have not started executing. When I select "Cancel workflow" in the GitHub web interface, I receive the error "Failed to cancel workflow."

These runs were created during the November 11 GitHub Actions service disruption.

Is this a known issue involving stuck workflow runs or check suites? Can GitHub investigate whether these runs need to be cleared or reset?

I have screenshots showing the queued workflows and the cancellation error.

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

[kmcclellan]

Same issue here: https://github.com/kmcclellan/kafka-di/actions/runs/43098527902

I tried "force cancel" mentioned in the help content but I get an HTTP 409 with an error “Cannot cancel a workflow run that has not been queued yet.”

Guess they need to build a "force force cancel" :D

[stephentaghan-a11y]

LOL! 😂 I could really use that “force force cancel” button right now! Thanks for the laugh!

[ismaelmoyaho]

Same issues here: https://github.com/ismaelmoyaho/ayunovni/actions/runs/43096076527
Tried force cancel and got:
"message": "Cannot cancel a workflow run that has not been queued yet.",
"documentation_url": "https://docs.github.com/rest/actions/workflow-runs#force-cancel-a-workflow-run",
"status": "409"

I tried a manual workflow and it works, so I guess that run will stay queued forever.

[eyjayjay-collab]

Seeing a similar issue with a push-triggered CI run on main in a private repository. The run was queued on November 11 at 20:25 UTC and was still queued on attempt 1 after GitHub reported recovery. The jobs API returned total_count: 0, and the same workflow passed on the PR before merge.

We haven’t tried canceling because successful CI triggers our deployment automatically, and we want to avoid a duplicate. Has anyone seen an original run in this state resume? Is there a GitHub-recommended recovery for runs that stayed queued without creating jobs?

[mhseo1026]

We are experiencing the same issue.

Our pull_request workflow run was created at approximately 20:41 UTC on November 11, 2026, shortly before the reported GitHub Actions disruption.

The run remains stuck in the Queued state.

Additional findings:

• The GitHub Jobs API returns an empty jobs array.
• The standard "Cancel workflow" action fails with "Failed to cancel workflow."
• The pull request remains open.
• The same commit passed the previous branch CI.

Has GitHub identified a recovery procedure for these stuck workflow runs?

We would appreciate any official guidance.

[nimson07]

Same issue here. Private repo, push-triggered run on develop, created about 20:25 UTC on Nov 11, 2026, still status: queued (attempt 1) more than 4 hours later. “Cancel workflow” in the UI fails with “Failed to cancel workflow”, and force-cancel returns HTTP 409 “Cannot cancel a workflow run that has not been queued yet”. gh run cancel says “Cannot cancel a workflow run that is completed”, while the runs API returns status: queued, conclusion: null. So the run state looks internally inconsistent. Three other workflows triggered in the same window (a pull_request run and two push runs) are stuck the same way. Runs from before about 20:25 completed normally. Hoping for official guidance on clearing or recovering these runs.

The jobs API returns total_count: 0 for the run.

[100rootrain]

Here's what I found after going through the reports in the community since the incident.

What's happening. The Nov 11 incident (Actions, Pages, Webhooks and Copilot, 20:48–21:21 UTC) was marked resolved with "the backlog of Actions jobs has been fully processed." Runs created around 20:20–20:50 UTC were left in an inconsistent state, though:

• The run shows queued, but the jobs API returns total_count: 0.
• Cancel workflow fails.
• Force-cancel returns 409 Cannot cancel a workflow run that has not been queued yet.
• gh run cancel says the run is already completed.

This isn't caused by your workflows. Of the 95 discussions opened here since 20:00 UTC, 69 are this same problem. As of 03:27 UTC today, the public runs I checked were all still stuck. They aren't clearing on their own so far, and no GitHub staff have responded in any of these threads yet.

What works right now: start a fresh run. New runs are processed normally. For example, in kmcclellan/kafka-di, the release run from 20:52 UTC is still stuck, while the workflow_dispatch runs started today ran normally.

• PR or push workflows: push an empty commit. This was confirmed in GitHub Actions workflows stuck in Queued — cancellation fails #212811 to re-trigger all checks on a PR.

  git commit --allow-empty -m "ci: retrigger after Actions incident"
  git push

• Workflows with workflow_dispatch: run them again from the Actions tab, or with gh workflow run <workflow-file> --ref <branch>.
• Pages ("pages build and deployment"): push a new commit to the publishing branch.
• If the new run waits as pending with a message about a concurrency group, the stuck run is holding that group. Temporarily change the group name in the workflow to get past it.

The stuck run will stay in your list. For deployment workflows, keep in mind it's not certain it will never be picked up later. If a duplicate deploy would be a problem, make sure your deploy step can safely run twice before you retrigger.

To get the stuck runs removed: GitHub Support. You can't cancel, re-run or delete them yourself. Results with Support have been mixed. Some people's tickets were closed straight away, but in #212827 one person reported that Support fixed their runs. When you open a ticket, include:

• the run URLs and their creation times,
• the incident link above,
• the API evidence (status: queued, jobs total_count: 0, the force-cancel 409),

so it's clear this is incident fallout and not a configuration question.

[jameswagnerjr]

I just got a reply to my support ticket:

These workflow runs were left in an incomplete state by the incident, which is why re-running it keeps failing and no new attempts are recorded. Re-running that specific run won't help. Instead, start a fresh run with Run workflow, as described in Manually running a workflow, and it should start normally. The stuck runs should clear on their own within about 24 hours.

[cmartinez-st]

We are seeing the same symptoms and would appreciate an official private escalation path from GitHub staff.

Our latest read-only checks show:

• One workflow run remains queued, with conclusion: null and zero jobs.
• The UI cancellation reports Failed to cancel workflow.
• Both the standard cancel and force-cancel API requests returned HTTP 409.
• Other later workflow runs completed successfully, so this is not evidence that all Actions execution is blocked.

We have stopped repeating cancellation requests and have not deleted or rerun the stuck execution.

The official troubleshooting guide describes this combination of symptoms and recommends Support assistance: https://docs.github.com/en/actions/how-tos/troubleshoot-workflows#canceling-workflows

Could GitHub staff provide an official private channel to share the affected run identifier and request reconciliation of the run/check-suite state? The support portal currently does not offer an Actions technical-support category for our account. We are deliberately not publishing repository names, private URLs, run identifiers, commit SHAs, logs, or credentials here.

We are seeking reconciliation of the stuck state while preserving audit history, not another workflow trigger or a workaround that bypasses safety checks. Thank you.

[scolastico]

I allready asked the github support, its fucking stupid they know it but fixing it is basically our job:

Hello,

Thank you for reaching out to GitHub Support!

This was caused by a GitHub Actions incident on our side, not by your workflow, policies, or limits. Between roughly 20:16 and 21:00 UTC on November 11, Actions couldn't create new workflow runs across GitHub.com. Your dispatch landed in that window. Our logs show a platform-side error that would've been retried automatically, with nothing pointing to your configuration.

The public notice is the Impact across multiple GitHub products including Actions, Pages, and Copilot products incident. It was posted at 20:48 UTC and resolved at 21:21 UTC.

These workflow runs were left in an incomplete state by the incident, which is why re-running it keeps failing and no new attempts are recorded. Re-running that specific run won't help. Instead, start a fresh run with Run workflow, as described in Manually running a workflow, and it should start normally. The stuck runs should clear on their own within about 24 hours.

If your workflow uses a concurrency group and the new run waits behind the stuck one, you can rename or create a new concurrency group in order to immediately unblock yourself, or alternatively let us know and we'll clear the stuck workflow runs for you.

For reference, Re-running workflows and jobs covers re-run behavior in general, but in this case a new run is the way forward.

Nothing on your side needs to change.

Please let me know if you have any further questions about this in the meanwhile!

Regards,
Ben

[ctm-matsuzaki]

We are experiencing the same issue with GitHub Pages.

Repository:
https://github.com/ctm-matsuzaki/ctm-matsuzaki.github.io

Affected run:
https://github.com/ctm-matsuzaki/ctm-matsuzaki.github.io/actions/runs/42720435508

The run remains queued with zero jobs. Both cancel and force-cancel return HTTP 409.

Cancellation succeeded once, but rerunning the workflow left it queued again. Our website updates cannot be published.

Could GitHub staff investigate and clear the stuck workflow run or check suite?

[romangurinenko-beep]

Four pull_request workflows on one unchanged commit in a private repository have remained queued since 11 November2026 around20:55UTC. They use ordinary ubuntu-latest GitHub-hosted runners and have no concurrency group. All are still attempt1 with zero jobs and artifacts; the candidate package was not built. The public incident dvy0t3mvh1lg was resolved around21:21UTC, but these runs did not recover.

One ordinary cancellation did not clear the CI run. One documented force-cancel request returned HTTP409Conflict, and subsequent reads still show queued/zero jobs. We have not created duplicate workflows/builds, deleted runs, changed permissions, or pushed another commit.

The account's Support portal says Technical support not included and offers no Actions technical ticket. What is the supported way to ask GitHub staff to safely reconcile or terminalize these orphaned runs while preserving their evidence? We can supply exact run identifiers through an appropriate private GitHub channel if staff requests them. We are not requesting paid support or plan changes.

[maytyafx-debug]

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

On November 11, 2026, two pull_request workflow runs and several push-triggered runs on the main branch became stuck in the Queued state.

Observed details:

• The two pull_request runs remain queued.
• The Jobs API returned an empty jobs array for both runs.
• The Frontend CI usage page showed 0 seconds of runtime.
• Other workflow runs in the same repository have completed successfully in the past.
• Repository Actions permissions were reviewed and saved.
• The issue persisted after reviewing the repository Actions settings.

This appears consistent with the November 11 incident reports in this discussion.

Could GitHub staff confirm whether these runs were left in an incomplete state and advise on a safe recovery procedure?

The repository is private, so I have intentionally omitted its name, run IDs, and commit SHA from this public comment. I can provide those details through an appropriate private support channel if available.

Thank you.

[kulikovroman08]

I'm experiencing the same issue with GitHub Actions in my public repository.

Repository: https://github.com/kulikovroman08/goforge-web

Several workflow runs have been stuck in the queued state with zero jobs since November 11, 2026.

When I try to cancel them, GitHub displays "Failed to cancel workflow".

Affected workflow run IDs:

• 43095930636
• 43095858324
• 43095813713
• 43095750540
• 43095703839
• 43095649344
• 43095645585
• 43095573883
• 43095388631

Additionally, the latest GitHub Pages deployment failed with startup_failure:

https://github.com/kulikovroman08/goforge-web/actions/runs/43095930231

Previous workflow runs and Pages deployments completed successfully.

Could someone from the GitHub team investigate this issue or suggest how to clear these stuck runs and restore deployment functionality?

[SrDevGui]

Same problem here in a private repository, I try to cancell but returns an error

[chrfranke]

Same issue here: https://github.com/smartmontools/smartmontools/actions?query=is%3Aqueued

There was also an unexpected large increase of "Total minutes" which IMO cannot be explained with the other runs:
https://github.com/smartmontools/smartmontools/actions/metrics/usage?dateRangeType=DATE_RANGE_TYPE_CUSTOM&range=1794268800000-1794441600000