GitHub Actions・2026年11月3日に確認

GitHub Actions：「The hosted runner lost communication with the server」

ジョブの途中でランナーが GitHub への報告をやめ、GitHub があきらめた、という意味です（「ホストのランナーがサーバーとの通信を失った」）。停止の合図のときと違い、ランナーは理由を言う間もなかったので、ログが無いことがよくあります。たいていはジョブ自身がマシンを使い切ったせいですが、そうでないこともあります。

見え方

2026年11月2日の公開の実行（runs-on: windows-2025）での、ジョブの注釈です：

The hosted runner lost communication with the server. Anything in your workflow that terminates the runner process, starves it for CPU/Memory, or blocks its network access can cause this error.

ジョブは失敗になります。動いていたステップは「実行中」のまま残り、後処理（Post）のステップは始まりません。
ログは消えていることが多く、取りに行くと 404（BlobNotFound）です。その実行では、ステップが出力をファイルに貯めて最後に出す作りだったので、何も GitHub に届きませんでした（soldr #4072）。
GitHub が知らせるのは、ランナーが止まってから数分後です。あるプロジェクトの測定では約10分で、ランナーが19時50分58秒に止まり、メッセージは20時0分36秒でした。そのため、ジョブは実際の作業より長く見えます（hyperskill-plugin #67）。
セルフホストのランナーでは、メッセージは「The self-hosted runner lost communication with the server」で始まります（同じ報告）。

理由

メモリ。ステップとして入れたセキュリティのエージェントが、プロセスを多く作るテストの下で1分に約200 MiB ずつ増え、16 GB のランナーが止まりました。外すと、同じシャードは3〜4.2 GB のままでした（boost #1301）。セルフホストのランナーのポッドでは、9〜10 GB ずつのジョブ2つが、使える量が約14 GB のノードを分け合い、先に進んでいた方が止められました（hyperskill-plugin #67）。同じ負荷が、代わりに「The runner has received a shutdown signal」で終わることもあります。
ディスク。管理しているファイルが約53 GiB あるリポジトリでランナーのディスクが埋まり、ランナーは自分のログも書けなくなり（「No space left on device」）、そのジョブの1つがこのメッセージで終わりました（single-stock-investments #1473）。
CPU。Windows で、重い作業がランナーのプロセスを押しつぶさないよう、優先度を「通常以下」にして動かすようにしたプロジェクトがあります（soldr #4072）。
ネットワーク：メッセージのとおり、ジョブの中でランナー自身の GitHub への接続をふさぐものも原因になります。
ときどき、ワークフローに原因が無いこともあります。あるプロジェクトでは、失敗した実行200本の中でこの形は2本だけで、ジョブは3秒でランナーを得ていて、同じ作業を測るとメモリは16 GB のうち最大5.9 GB でした（omni #3517）。

手がかりを残す

最後にまとめて出さず、進むたびに出す：バッファしない出力（Python なら PYTHONUNBUFFERED=1）と、段階ごとの始まりと終わりの1行（soldr #4072）。
ログが丸ごと消えることがあるので、ログに書いた測定は残らないかもしれません。あるプロジェクトは、メモリ・ディスク・プロセスの様子を10秒ごとに別のチェックランへ送り、ランナーが止まった後もデータが残るようにしました（hyperskill-plugin #67）。
重いステップの前後でディスクを見る：df -h。

どうするか

メモリの山を下げる：並ぶプロセスを減らす。限りなく増えるステップがあれば外す（boost #1301 は1つのジョブだけで外しました）。

取り出す量を減らす：ジョブに要る分だけの sparse checkout。

- uses: actions/checkout@v7
  with:
    sparse-checkout: |
      src
      scripts

セルフホストのランナーでは：ノードあたりのランナーのポッドを減らすかポッドごとにメモリの上限を付ける、ノードの大半を使うマトリックスのジョブには max-parallel: 1、テストの前にビルドのデーモン（Gradle・Kotlin のコンパイラ）を止める（hyperskill-plugin #67）。
再実行：Re-run failed jobs、または gh run rerun <run-id> --failed。自動で再実行するなら、ログは消えていることがあるので、ログではなく注釈を見てください：
```
gh api repos/OWNER/REPO/check-runs/JOB_ID/annotations --jq '.[].message' | grep -q "lost communication with the server"
```
デプロイの自動の再実行には気を付ける。omni #3517 は、失敗したジョブ全部がランナーを失っていて、新しいリリースの実行が無いときだけ、最大2回まで再実行し、Terraform や Pulumi のジョブが途中で止まったときは再実行しません。状態のロックと、半分だけ適用された構成が残りうるためです。

見分け方

ランナーが止まるよう合図を受けた：ログが終了コード143と「The runner has received a shutdown signal」で終わります（どうするか）。
ジョブの時間の上限：ジョブは Cancelled で終わり、「The job has exceeded the maximum execution time」が出ます（どうするか）。
どのランナーもジョブを受け取らなかった：ランナーもステップもありません（「The job was not acquired by Runner of type hosted」）。

ランナーを失ったジョブを IntelliJ IDEA から見るなら

Pipeline Inbox for GitHub Actions Workflows は、Lesstep が作っている JetBrains IDE（2024.1 以降）のプラグインです。すべてのリポジトリの実行を、ジョブ・ステップと一緒に IDE のツールウィンドウに並べるので、通ったジョブの横で、失敗したジョブが目立ちます。いまのブランチの実行はステータスバーに出ます。読むのは無料、失敗したジョブの再実行・キャンセル・ワークフローの実行・デプロイのレビューは Pro（月 US$1.50・30日の無料試用つき）です。

GitHub と GitHub Actions は GitHub, Inc. の商標、IntelliJ IDEA は JetBrains s.r.o. の商標です。このページは GitHub, Inc.・JetBrains のいずれとも提携しておらず、承認も受けていません。

ほかに：「The runner has received a shutdown signal」 · 「The job has exceeded the maximum execution time」 · デバッグログ付きでジョブを再実行する · IntelliJ IDEA で使える GitHub Actions のプラグインの比較 · English