with one click
github-actions-hosted-runner-cancelled-job-diagnosis
// Diagnose GitHub Actions runs that appear as failures but whose jobs were actually cancelled before any step started because a GitHub-hosted runner was never acquired.
// Diagnose GitHub Actions runs that appear as failures but whose jobs were actually cancelled before any step started because a GitHub-hosted runner was never acquired.
[HINT] Download the complete skill directory including SKILL.md and all related files
| name | github-actions-hosted-runner-cancelled-job-diagnosis |
| description | Diagnose GitHub Actions runs that appear as failures but whose jobs were actually cancelled before any step started because a GitHub-hosted runner was never acquired. |
| version | 1.0.0 |
| author | Hermes Agent |
| license | MIT |
| metadata | {"hermes":{"tags":["github","actions","ci","debugging","runner","hosted-runner"]}} |
Use this when a user gives you a GitHub Actions run/job URL and asks why it failed, especially when the UI says failure but the job page shows little or no log output.
A workflow run can end with overall conclusion: failure even though the actual job never executed repository code.
Typical signature:
conclusion is cancelledsteps is emptygh run view --job ... --log returns log not foundrunner_id: 0gh run view --verbose shows an annotation like:
The job was not acquired by Runner of type hosted even after multiple attemptsWhen these all line up, the root cause is GitHub-hosted runner acquisition failure, not a failing build/test/deploy command.
Always use gh through the governed form:
env -u GITHUB_TOKEN gh run view <RUN_ID> --json name,displayTitle,event,status,conclusion,headBranch,headSha,url,jobs
env -u GITHUB_TOKEN gh run view <RUN_ID> --verbose
Then inspect the raw job object:
env -u GITHUB_TOKEN gh api repos/<owner>/<repo>/actions/runs/<RUN_ID>/jobs
If you need the specific job/check-run details:
env -u GITHUB_TOKEN gh api repos/<owner>/<repo>/check-runs/<JOB_ID>
You likely have repository or workflow logic problems when:
Then debug the failing step itself.
You likely have GitHub infrastructure/scheduling failure when:
runner_id: 0)cancelledThen do not blame checkout/build/deploy scripts.
These help rule out adjacent causes:
# inspect .github/workflows/<file>.yml
Look for:
concurrency:cancel-in-progress: trueCheck environment protection rules if the job targets an environment.
Check whether steps started at all.
Summarize clearly:
First response:
If it repeats:
Observed production deploy case:
conclusion: failureDeploy conclusion: cancelledsteps: []runner_id: 0gh run view --verbose annotation: The job was not acquired by Runner of type hosted even after multiple attemptsThis is the canonical pattern for this skill.