GitHub Actionsが始まらない・止まった時の対処|障害とランナー待ちの切り分け

GitHub ActionsがQueuedのまま進まない時、サービス障害のほかに、ランナー不足、承認待ち、同時実行の制御があります。失敗ジョブを連打で再実行する前に、どの段階で止まったかを確認しましょう。

【要点】キュー待ちと実行中の停止を区別

• ワークフロー実行ID、コミット、止まったジョブ名を控えます。
• ホスト型ランナーか自社ランナーかを確認します。
• 環境の承認やconcurrencyの待機を調べます。
• デプロイ・通知・DB変更を含むジョブは、結果確認前に再実行しません。

公式サービス障害モニターほかのサービスの障害・メンテナンス・復旧履歴を確認

GitHub Actionsの公式公表です。自社のランナーマシンや、ジョブが接続する外部サービスの状態は、この表示だけでは分かりません。

止まった段階で調べるもの

実行画面を確認する手順

1. Actionsで対象の実行を開き、実行ID、開始時刻、コミットを保存します。
2. 待機なのか実行中なのかを見て、ジョブとステップのどちらまで進んだかを確認します。
3. 直前の設定変更と比較し、実行対象のブランチやイベント条件が一致しているか調べます。
4. 複数リポジトリで共通して失敗するのか、一つのワークフローだけかを確認します。

失敗ログの末尾にある一般的な終了コードだけでなく、先に出た具体的なエラーを読みます。依存パッケージの取得失敗は配布元の問題、認証エラーはシークレットや権限の問題かもしれません。GitHub公式のワークフロー診断と照合します。

自社ランナーが待機の原因になっていないか

管理権限のある担当者は、リポジトリ・組織の設定からActionsのRunnersを確認します。Offlineなら、端末の起動、ランナーサービス、ネットワークを調べます。Idleでも、ワークフローの runs-on とラベル・グループが合わなければそのジョブには割り当てられません。

自社ランナーの割り当ての仕様と公式のランナー診断手順を確認してください。ログの収集時はトークンや機密の環境変数を公開しないようにします。ランナーの再登録・削除は、実行中のジョブがないことを確かめてから管理者が判断します。

再実行前に副作用を確認する

「失敗」と表示されても、デプロイ、通知メール、DB変更の一部は完了している場合があります。デプロイ先のバージョン、変更履歴、外部処理IDを確認し、どこからやり直せるか決めます。全ジョブを一括で再実行するより、失敗工程だけを安全に再開できるかを検討します。

concurrencyで待っている場合、先行ジョブを止めればよいとは限りません。先行の本番更新中に後続を走らせるとデータ不整合を起こすため、担当者の手順に従います。承認ルールを外すことも、障害時の標準的な対処ではありません。

再実行する前に、完了したステップを調べる

ワークフローが失敗と表示されても、すべての処理が取り消されたとは限りません。成果物のアップロード、外部サービスへの通知、本番DBへの変更などが完了してから後続ステップで止まる場合があります。最後に成功したステップと配信先の記録を照合し、再実行で重複する処理がないかを担当者が確認します。

待機中の場合は、実行可能なランナーがあるか、承認が必要かを調べるのが先です。障害と思って同じ実行を増やすと、復旧後に古い処理まで一斉に進むことがあります。キャンセルする場合も、処理済みの副作用を元に戻す操作ではない点に注意します。復旧テストは可能なら本番変更を伴わないジョブで行い、配信再開は対象コミットと実行順を決めて進めてください。

まとめ

Actionsの停止は、待機・承認・実行ステップに分けて調べます。復旧後はキューに残った古い実行を確認し、不要なデプロイが順番に走らないよう管理します。最新のコミットだけでなく、実際の配信先が意図した状態になったかまで確認してください。

国内の通信・アプリ・企業システム障害のまとめを見る