My rerunned workflow url is https://github.com/PerformanceScoring/secureDB/actions/runs/34630213491.

The linked run is private, but with ARC a job that stays queued usually means no online idle runner matches every requested label or runner group. Compare the job labels with the registered runners:

gh api repos/PerformanceScoring/secureDB/actions/runs/34630213491/jobs \
  --jq '.jobs[] | {name,status,labels,runner_name}'
gh api repos/PerformanceScoring/secureDB/actions/runners \
  --jq '.runners[] | {name,status,busy,labels:[.labels[].name]}'

If runner_name is null, make runs-on match the ARC runner-scale-set name/labels exactly, then inspect the controller and listener pods. Re-running will not fix an offline or mismatched pool. References: using self-hosted runners and ARC troubleshooting.

We are seeing a GitHub-hosted Actions job remain queued without receiving a runner.

Environment

• Private organization repository
• Standard GitHub-hosted runner
• Runner label: ubuntu-latest
• Trigger: workflow_dispatch
• Workflow uses a concurrency group with cancel-in-progress: false

Timeline

• Run created: 2026-09-12 22:35:32 UTC
• Job queued: 2026-09-12 22:35:38 UTC
• Still queued at: 2026-09-12 23:49:00 UTC
• Total queue time so far: over 73 minutes
• The run’s updated_at value has not changed since 22:35:39 UTC

Observed state

• Run status: queued
• Job status: queued
• Runner name: empty
• Steps executed: 0
• Pending environment deployments: none
• Other queued or running jobs in the organization: none

Checks completed

• GitHub Actions is enabled.
• ubuntu-latest is a valid runner label.
• The Actions budget has not been reached.
• No environment reviewer or wait timer is blocking it.
• No other run appears to hold the concurrency group.
• This workflow has completed successfully previously.
• GitHub Status reports Actions as operational.

We have intentionally not cancelled or redispatched the job yet, so the original scheduler state remains available for investigation.
Is this a known GitHub-hosted runner scheduler issue? Can a GitHub administrator inspect why no runner was assigned and confirm whether cancelling and redispatching is the recommended recovery?