A queued job is a symptom, not a diagnosis. Start with current GitHub Actions status and read any incident's affected scope. A quiet provider page does not prove your repository or runner is healthy, and a GitHub-wide incident may concern a different component.
Find the point where progress stopped
Open the run and the specific job. Record its waiting message, when it entered the queue, and whether other jobs have started. Distinguish a workflow that never triggered from an existing job that cannot get a runner. Those are different investigations.
| What you observe | First useful check |
|---|---|
| No run exists for the expected event | Review the event, branch filters and workflow configuration |
| A job waits for a runner | Check the requested runner and its availability |
| A deployment waits for review | Open the deployment approval details |
| Several independent repositories stall together | Compare start times and affected scope with official notices |
Preserve the original run URL. Creating several replacements makes the timeline harder to understand and can create duplicate deployment attempts.
Check the runner your job actually requests
Read the job's runs-on selection. For a self-hosted runner, inspect its state in the repository or organization settings. An offline runner needs a different investigation from an online runner occupied by another job. Confirm that labels and access allow this repository to use it. GitHub documents runner states and the diagnostic logs to inspect in its self-hosted runner troubleshooting guide.
If you manage the runner, preserve the relevant logs before restarting its service. Review them privately; logs can contain internal paths and other sensitive context. If you do not manage it, send the run URL and waiting message to the owner.
Check concurrency and approvals
A concurrency group can deliberately hold a job while another run occupies that group. Inspect the group expression and the older run before changing the configuration. GitHub supports different pending-queue behavior and cancellation settings; use its current concurrency documentation rather than assuming every pending job behaves the same way.
Do not remove production serialization simply to shorten a queue. Establish whether the earlier deployment completed before canceling or replacing it. If the interface names a required approval, ask the designated reviewer to inspect it.
Choose the next action from the evidence
When an official incident names Actions and matches your symptom, follow its updates and keep the original run for comparison. When only one runner or repository is affected, continue with its configuration and logs. If neither explanation fits, the cause is still undetermined.
A useful support note includes the run URL, job name, runner type, exact waiting message, first observed time with timezone, and whether another repository reproduces it. Keep tokens and private log contents out of public reports.
Follow Actions provider alerts or review the wider GitHub status. Alerts describe published provider evidence; they do not monitor execution inside your repository.