GitHub Actions Stuck in 'Queued' Limbo: A Challenge for Software Monitoring

GitHub Actions Workflows Stuck in 'Queued' Limbo: A Challenge for Software Monitoring

GitHub Actions are a cornerstone of modern software development, enabling automated CI/CD pipelines that boost developer productivity. However, even robust systems can encounter peculiar edge cases. A recent discussion in the GitHub Community highlights a particularly frustrating bug where workflow runs get stuck indefinitely in a 'queued' state, becoming impossible to cancel or manage. This scenario presents a significant hurdle for effective software monitoring and can disrupt progress on key developer OKR examples.

The Uncancelable Queued State

The issue, reported by TRGamer-tech, involved two manually dispatched workflow runs for a 'Rezeptindex' workflow. These runs entered a 'queued' status but never spawned a single job. Crucially, they could not be cancelled through either the GitHub REST API or the web UI:

• REST API Cancellation: Attempts to cancel via POST /actions/runs/{run_id}/cancel returned a 409 Conflict error with the message:

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

• Web UI Cancellation: The web interface similarly failed, returning an HTTP 422 Unprocessable Entity with the body {"message":"Failed to cancel workflow."}.

This contradictory state—being 'queued' but simultaneously reported as 'not queued yet' for cancellation purposes—points to a deeper platform-level inconsistency. Other workflows on the same repository and commit ran successfully, and GitHub's status page showed no incidents, further isolating the problem to these specific runs.

Initial Hypotheses and The Realization

Community member dosymep initially suggested that outdated GitHub Actions versions might be the culprit. The idea was that referencing older action versions (e.g., actions/checkout@v4 when v5 is available) could cause workflows to stall in the queue. TRGamer-tech investigated this, noting that the same workflow files with the 'outdated' actions had run successfully both before and after the stuck runs.

Despite this, TRGamer-tech proceeded to update all actions to their latest major versions (e.g., checkout@v5, upload-pages-artifact@v4). The outcome was telling:

• New runs of the updated workflow functioned perfectly, completing without issues.
• The original stuck runs (#69 and #70) remained in their 'queued' state, uncancelable, and with empty job lists.

This confirmed that while updating actions might resolve issues for *new* workflow dispatches, it offered no remedy for the already-stuck runs. The problem persists, leaving these phantom runs to potentially block concurrency groups and skew software monitoring dashboards.

Implications for Developer Productivity and Monitoring

Such an issue directly impacts developer productivity. Stuck runs can consume valuable concurrency slots, preventing other critical deployments or tests from running. For teams tracking developer OKR examples related to deployment frequency, lead time, or workflow success rates, these unmanageable runs introduce noise and can artificially depress metrics.

Effective software monitoring relies on accurate, actionable data. When workflow runs enter an indeterminate state that cannot be resolved by developers, it undermines trust in the system and complicates troubleshooting. This community insight highlights a need for GitHub to provide mechanisms to force-cancel or clear such orphaned workflow runs, ensuring that developers can maintain clean, reliable CI/CD pipelines.