GitHub ActionsのJobがQueuedのまま進まないとき、Runner待ちの原因を切り分ける

GitHub Actionsのworkflow runは作成されたのにjobがQueuedのままなら、まずjobに合うrunnerが見つかっているかを確認します。runが作られている状態はtriggerの成功を示しますが、jobが実行開始したことやrunnerに割り当てられたことは示しません。最初にrun詳細のstatus messageを読み、GitHub-hosted runnerの待ち行列なのか、self-hosted runnerのlabel・group・online状態なのかを切り分けます。

「Waiting for a runner to pick up this job」と表示される場合でも、原因をrunner台数不足と決めつけないでください。runs-on条件の不一致、runner groupのrepository access、runner offline、同時実行制限、GitHub側の障害など、実行開始前に詰まる場所は複数あります。設定を広げる前に、jobの要求と利用可能なrunnerの条件を照合します。

まず確認するrunとjobの状態

対象workflowのrunを開き、jobがどの状態か確認します。run全体がQueuedなのか、job単位のQueuedなのか、Environment approval待ちなど別状態なのかを混同しないでください。run URL、job名、発生時刻、ref、commit SHA、表示されたmessageを記録します。

• Queued / Waiting for a runner：jobはまだrunnerに割り当てられていない可能性があります。runs-onとrunner条件へ進みます。

• In progress：runnerがjobを開始しています。Queued問題ではなく、step開始後の遅延・失敗を調べます。

• Pending approval：Environmentなどの承認待ちを確認します。runnerのlabelを変更しても解決しません。

• Skipped / Cancelled：job condition、dependency、concurrency設定を確認します。runner選択だけの問題とは限りません。

• workflow run自体がない：triggerの問題です。scheduleが発火しない記事の診断対象で、runner待ちとは別です。

画面に表示される文言は画面やrunner種別によって異なります。status messageをそのまま記録し、似た症状の別jobと混ぜないようにします。

Hostedかself-hostedかを識別する

workflow YAMLの該当jobにあるruns-onを見ます。GitHub-hosted runnerなら、ubuntu-latestなどGitHubが提供するlabelやrunner groupが使われています。self-hostedなら、通常はself-hosted labelとOS・architecture・独自label、またはgroup指定があります。matrixでlabelが組み立てられる場合は、実行されたmatrix値も確認します。

表は横にスクロールできます

確認対象	見る場所	判定
runs-on	jobのworkflow YAML	実際に要求するOS、architecture、label、group
runner種別	label / group / repository設定	GitHub-hostedかself-hostedか
run ref	run詳細	想定したブランチとcommitか
job status message	runのjob詳細	runner待ち、approval、condition等の区別
runner状態	Settings → Actions → Runners	self-hostedならIdle / Active / Offline
group access	Organization / Enterprise runner設定	対象repoとworkflowに利用権限があるか

手動runが別branchや別入力で成功していた場合、問題のrunと同じruns-on条件を使っているかも比べます。「同じworkflow名」でも、別のcommit・matrix値・job conditionなら比較対象として不十分です。

self-hosted runnerを確認する

Self-hosted runnerは、jobのruns-onに指定されたlabelとgroupの両方に一致する必要があります。GitHubは一致するonlineかつidleのrunnerを探します。候補がなければrunnerがオンラインになるまでjobはQueuedのままです。runの状態が24時間以上続くとjobが失敗するため、長時間放置せず、runner側の状態を確認します。

1. RepositoryまたはOrganizationのSettingsでActions → Runnersを開く。

2. runner name、labels、group、statusを確認する。

3. jobのruns-onに書かれたlabel/groupと、登録runnerのlabel/groupを照合する。

4. Offlineなら、実行マシン、runner application/service、GitHubとの通信を管理者と確認する。

5. Idleなのに割り当てられないなら、対象repoがrunner groupで許可されているか、workflow制限があるかを確認する。

6. 必要な権限が分からない場合、group visibilityを広げず管理者へrun URLと条件を渡す。

GitHub公式資料では、onlineでidle、かつ条件に合うrunnerがあればjobへ割り当てられます。runnerが割当後60秒以内にjobを取得しない場合、jobは再度queueへ戻されることがあります。self-hosted runnerがOfflineなら、マシン停止、runner app停止、GitHubへ通信できない状態などが原因候補です。画面のstatusだけで原因を断定せず、runnerログやservice状態を運用者に確認してもらいます。

Runner labelを追加したりgroup accessを緩めたりするのは、必要なrunner条件と安全境界を理解した後です。特にOrganization runnerを広い範囲へ許可すると、対象外repositoryからrunnerを使える状態になり得ます。特定jobを動かすために自分で権限境界を広げず、管理者に最小範囲の変更を依頼します。

GitHub-hosted runnerを確認する

GitHub-hosted runnerでは、repositoryやorganizationのActions設定、job concurrency、アカウントやplanの利用上限、GitHub側の状態を順に確認します。GitHub-hosted runnerにも利用可能な同時実行枠などの制約があり、planやrunner typeで条件が異なります。特定の枠数をすべてのrepositoryに当てはめず、GitHub Docsの現在のlimitsと対象accountの画面を照合してください。

同じ時刻に複数のworkflowが走るなら、concurrency groupの設定やqueue方針を調べます。GitHub Docsのlimitsにはconcurrency groupのqueue上限などが記載されているため、設定したqueue方式と現在の上限を確認します。枠を増やす有料runnerを使う前に、利用権限と追加費用が発生するかを確認してください。runner種別・plan・organization設定を知らずに「capacity不足」と結論づけないことが重要です。

GitHub Statusを確認し、Actionsに障害や性能低下が掲載されているかを見ます。障害が掲載されていれば、YAMLを変更する前に発生時刻とstatusの状況を記録し、復旧後に同じjobが動くか確認します。Statusに問題がなくても、個別repositoryの設定が正しいことの証明にはなりません。

runnerに割り当てられた後は別の問題として追う

runがIn progressになったら、runner待ちは解消しています。stepが始まった後に止まる場合は、setup、checkout、依存関係の取得、権限、ネットワーク、job scriptのログを見ます。Queuedの表示が消えた時刻と最初のstep開始時刻を記録すれば、runnerへの割当遅延とstep実行時間を分けられます。

runのjobがskippedなら、job condition、needsの結果、branch条件を確認します。Environment approval待ちなら、必要なreviewerを確認します。これらはrunnerの台数やlabelとは別の制御です。状態を取り違えてruns-onを変更すると、権限や運用を広げても解決しない変更になります。

診断例：labelが一致しない

たとえばworkflowがLinuxとbuildという2つのlabelを要求しているのに、利用可能なself-hosted runnerがLinux labelしか持たない場合、onlineでidleでもjobへ割り当てられません。run詳細でrunner待ちを確認し、YAMLの要求labelとSettings画面のrunner labelを一つずつ照合します。必要ならrunner管理者に、対象repositoryで許可されたrunnerがbuild labelを持つか確認します。

ただし、labelを外せば必ず安全に動くとは限りません。runner labelはOSだけでなく、必要なtoolchain、隔離環境、ネットワーク境界を選ぶ目的で使われる場合があります。要求labelを削除する前に、そのrunnerで処理してよいjobか、Secretsやdeploy権限が渡るかを管理者と確認します。YAMLのlabelだけを変えて、実際の実行環境を確認しない変更は避けます。

管理者へ渡す記録

次の項目を一つのhandoffにまとめると、runner管理者やGitHub Supportが状況を再現しやすくなります。

• Repository、workflow名、job名、run URL

• 発生時刻と継続時間、status message

• 対象ref、commit SHA、matrix値

• runs-onのlabel/group（秘密情報を含むYAML部分は除く）

• GitHub-hosted / self-hostedの区別

• self-hostedならrunner name、label、group、Idle/Active/Offline

• repository/group accessとworkflow restrictionの確認結果

• Actions status page、runner log、最初のstep開始有無

• 確認済み条件と未確認条件

token、秘密値、private keyをhandoffへ含めないでください。runnerログを共有する場合も、credentialや内部データがないか確認してから渡します。

変更前後の安全な確認

まずYAML、runner設定、run状態を保存し、原因仮説を一つに絞ります。label mismatchが確認できたら、必要なrunnerへ最小限のlabel変更を提案します。group accessが原因なら対象repositoryに限定した許可を管理者へ依頼します。GitHub-hostedのcapacity待ちなら、無関係なself-hosted runnerへ切り替える前にaccountのlimitとGitHub Statusを確認します。

変更を適用した後は、問題のjobを一度だけ再実行し、runがQueuedからIn progressへ進んだか、実際に選択されたrunnerが意図した範囲かを確認します。runが進まない場合は、設定を追加で広げず、表示message・status・timestampを更新して原因を再分類します。複数の設定を同時に変更すると、どの変更が効いたか判別できなくなります。

次にすること

1. Jobのstatus messageとrun URLを保存する。

2. YAMLからruns-on、matrix、groupを読む。

3. hosted/self-hostedを分け、self-hostedならonline/idleとlabel/group/accessを照合する。

4. hostedならConcurrency、plan/runner limits、GitHub Statusを確認する。

5. runnerに割り当て後の失敗はstep logへ切り替える。

6. 必要な変更は最小範囲に限定し、再実行で割当と実行開始を検証する。

Queuedを解消するためにrunner権限を広げることが目的ではありません。jobに要求された条件を満たすrunnerが、正しい範囲で利用可能かを特定するのが目的です。

公式Sources

• GitHub Docs, Self-hosted runners reference: https://docs.github.com/en/actions/reference/runners/self-hosted-runners（新しいタブで開く）

• GitHub Docs, Monitoring and troubleshooting self-hosted runners: https://docs.github.com/en/actions/how-tos/manage-runners/self-hosted-runners/monitor-and-troubleshoot（新しいタブで開く）

• GitHub Docs, Troubleshooting workflows: https://docs.github.com/en/actions/how-tos/troubleshoot-workflows（新しいタブで開く）

• GitHub Docs, Actions limits: https://docs.github.com/en/actions/reference/limits（新しいタブで開く）

• GitHub Docs, Choosing the runner for a job: https://docs.github.com/en/actions/how-tos/write-workflows/choose-where-workflows-run/choose-the-runner-for-a-job（新しいタブで開く）

• GitHub Status: https://www.githubstatus.com/（新しいタブで開く）

Checked: 2026-10-15

Editorial Note: GitHub公式資料を確認した一般的な診断ガイド。特定repositoryのrunner設定・plan・障害状態は確認していない。