GitHub Actions: 60 issue_comment runs stuck queued with zero jobs; force-cancel returns 409

[pjguti]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Workflow Deployment

Discussion Details

Summary

In a private repository on GitHub Free, 60 GitHub Actions workflow runs have remained in queued since November 11, 2026, between 20:21 and 20:42 UTC. The runs were created by five separate issue_comment events, each triggering 12 workflows (5 × 12 = 60).

All 60 runs have:

• status=queued, conclusion=null, and an unchanged updated_at timestamp.
• Zero jobs (GET /actions/runs/{run_id}/jobs returns total_count=0).
• No evidence that any runner was assigned.

All 12 workflows have job-level conditions that exclude the issue number from those events. Newer issue_comment events trigger the same workflows and correctly complete with conclusion=skipped and no runner assigned.

Cancellation attempts

The standard POST /actions/runs/{run_id}/cancel endpoint was tried on seven of these runs and rejected. After all 60 were individually checked to have zero jobs, a single guarded force-cancel attempt was made for one run:

• Run ID: 43097589601.
• POST /actions/runs/43097589601/force-cancel returned HTTP 409 Conflict.
• Request timestamp: 2026-11-12 06:23:44 UTC.
• GitHub X-GitHub-Request-Id: 83F4:140046:18DCBA:2E4CEE:6AF55B6F.

The run remains queued afterwards, still with zero jobs and the original updated_at. Its check suite (116711741527) is also queued with zero check runs. No further force-cancel attempts, deletion, reruns, restarts, or workflow modifications have been performed.

Current capacity signals

The repository's registered runners are currently reported online and busy=false; the Actions API reports zero in_progress runs. We have not treated those runner signals as evidence that all other workload capacity is guaranteed.

Questions for GitHub Actions / support staff

1. Is this a known Actions scheduler or check-suite consistency problem? Could the affected issue_comment events have been stranded during the November 11 service degradation?
2. Can GitHub safely reconcile the 60 stale queued workflow runs/check suites server-side, preserving normal audit history? We do not want to delete history or bypass workflow permissions.
3. Can you confirm whether runs with zero jobs in this condition consume any concurrency capacity or Actions minutes, or impede legitimate new workflow runs?
4. For GitHub Free accounts without ordinary technical support ticket access, what official escalation route is available to supply the full private-repository details securely?

A similar symptom is reported in Community discussions #212468 and #212707, though this report concerns a distinct batch of 60 events.

Privacy: This public post intentionally omits the private repository name/URL, local runner hostnames, credentials, internal architecture and private logs. If GitHub staff can provide an authorized private channel, we can supply the complete run IDs and traces.

No billing changes or paid support are requested.

[github-actions[bot]]

Thank you for your interest in contributing to our community! We currently only accept discussions created through the GitHub UI using our provided discussion templates. Please re-submit your discussion by navigating to the appropriate category and using the template provided.

This discussion has been closed because it was not submitted through the expected format. If you believe this was a mistake, please reach out to the maintainers.