Feb 10, 2026

GitHub Actions self-hosted runnerが止まる前の5項目チェックリスト

「昨日まで動いてたのに、急にジョブが走らなくなった」——self-hosted runnerを使っていると、一度はこの焦りを経験するのではないでしょうか。

原因を探ると、大抵は「ネットワーク設定が変わっていた」「runnerプロセスが落ちていた」「バージョンが古すぎた」といった、事前に気づけたはずのことばかり。止まってから調べ始めると復旧に時間がかかるので、定期的にチェックする習慣をつけておくと安心です。

この記事では、self-hosted runnerが止まる前に確認しておきたい5つの項目を紹介します。

1. HTTPS(443)の外向き通信と帯域は足りているか

self-hosted runnerは、GitHubのサーバーと常に通信してジョブの取得や状態の更新を行っています。この通信が途切れると、GitHub上では「Offline」と表示され、ジョブを受け取れなくなります。

確認すべきポイントは2つ。

70kbpsというのはかなり低い数値なので、通常のネットワーク環境なら問題になりません。ただ、社内ネットワークでプロキシ設定が変わった、VPNの経路が変更された、といったタイミングで疎通が切れることがあります。

最近インフラ周りで変更があったなら、一度確認しておくと良いです。

ファイアウォールで外向き通信を制限している環境では、GitHubの特定ドメインへのアクセスを明示的に許可する必要があります。

GitHub Enterprise Serverの公式ドキュメントでは、以下のようなドメインが例示されています。

注意点として、これらのドメインはCNAMEで別のホストを指していることがあります。ファイアウォールによってはCNAMEの追従が必要になるため、「ドメインは許可したのに繋がらない」という場合はこの設定を確認してみてください。

また、GitHubのドメイン構成は将来変わる可能性があるため、公式ドキュメントを定期的にチェックするのがおすすめです。

当たり前のようで見落としがちなのが、「そもそもrunnerアプリが起動していない」というケースです。

ホストマシンを再起動した後に手動起動が必要だったり、何らかのエラーでプロセスが落ちていたり。原因はさまざまですが、runnerプロセスが動いていなければジョブは受け取れません。

対策として、runnerをOSのサービスとして登録し、自動起動するよう設定しておくと安心です。Linuxならsystemctlで管理できます。

# サービスの状態を確認
sudo systemctl status actions.runner.<org>.<repo>.<runner-name>

サービス化しておけば、ホスト再起動後も自動で立ち上がりますし、プロセスが異常終了した場合の再起動も設定できます。

self-hosted runnerには自動更新機能があり、通常は新しいバージョンがリリースされると自動でアップデートされます。ただし、--disableupdateオプションで自動更新を無効化している場合は注意が必要です。

自動更新を無効化した状態で放置すると、原則30日以内に手動更新しないとジョブがキューされないなどの制限が発生する可能性があります。

さらに、GitHub公式のChangelogでは、2026年3月16日以降、v2.329.0以上が必須になると告知されています。これより古いバージョンでは、runnerの登録ができなくなったり、自己更新も動作しなくなる可能性があります。

2026年2月16日〜3月16日の間はbrownout期間として段階的にブロックが始まるため、早めにバージョンを確認しておくのが安全です。

# runnerのバージョン確認
./run.sh --version

GitHubの管理画面からrunnerの状態を確認できます。

Settings → Actions → Runners で、各runnerが「Idle」「Active」「Offline」のどの状態かが一覧で見えます。

ここで覚えておきたいのが、Offlineのまま長期間放置すると自動削除されるという仕様です。

一時的にrunnerを止めているつもりが、気づいたら登録が消えていた…という事態を避けるためにも、定期的にステータスを確認する習慣をつけておくと良いです。

月1回でも、インフラ変更があったタイミングでも、この5項目をざっと確認するだけで「突然止まった」を防げます。特にバージョン要件の強制は期限が決まっているので、早めに対応しておくと安心です。