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

GitHub Actions：「The job has exceeded the maximum execution time」

ジョブが時間の上限を超えたので、GitHub がキャンセルした、という意味です（「ジョブが最大の実行時間を超えた」）。上限は、ジョブの timeout-minutes（書かなければ360分）か、ランナー自身の上限の、先に来る方です。上げる前に、どのステップが動いていたか、遅かったのか止まっていたのかを確かめてください。

見え方

注釈は上限を時間の長さで示します。timeout-minutes: 20 なら 20m0s、90 なら 1h30m0s、既定の360なら 6h0m0s です。2026年11月2日の公開のジョブでは次のとおりでした：

The job has exceeded the maximum execution time of 20m0s

古い実行や多くの記事には、前の形「The job running on runner NAME has exceeded the maximum execution time of 360 minutes」が出てきます。

• ジョブは Failure ではなく Cancelled で終わります。動いていたステップは「実行中」のまま残り、その後のステップは、後処理（Post）のステップも含めて始まりません。
• 後ろの if: ${{ !cancelled() }} のステップも動きません。ジョブがキャンセルの扱いになるためで、そのジョブでは JUnit のアップロードが始まりませんでした（gh-widgets #286）。
• これに頼るジョブ（「全部のチェックが通った」を見る関門など）は失敗し（noter #94）、マージキューではプルリクがキューから外されます（下の freenet-core #6095）。

どの上限だったか

• ジョブの timeout-minutes：既定は360。ジョブが上のメッセージでキャンセルされます。
• ステップの timeout-minutes（最大360）：止まるのはそのステップだけで、「The action 'NAME' has timed out after 25 minutes.」で失敗します。ジョブはキャンセルではなく失敗になり、後ろの if: always() のステップは動きます。2026年11月1日の公開のジョブでは、タイムアウトしたステップの後で成果物のアップロードが動き、後処理のステップも動きました（Silinx-ISE #2462）。
• ランナーの上限：GitHub のホストのランナーで1ジョブ6時間、セルフホストのランナーで5日。timeout-minutes をそれより大きくしても効かず、ランナーの上限でキャンセルされます。
• ワークフローの実行全体：待ちと承認を含めて35日。
• セルフホストのランナーでは GITHUB_TOKEN が最長24時間で切れるので、それより長いジョブはタイムアウトの前に権限を失うことがあります。

全部のステップが通ったジョブ

2026年11月2日に2つのプロジェクトが報告しています。1つ目では、整形を確かめるジョブのステップが Complete job まで全部3分40秒で通り、ログの最後の行は Cleaning up orphan processes で、その約2分半後に「The job has exceeded the maximum execution time of 5m0s」でキャンセルされました（freenet-core #6095）。2つ目では、マージキューのジョブがステップを約4分40秒で終えたのに、7分でキャンセルされました。30回のうち3回です（claude-code-plugins #12506）。どちらも原因はまだ分かっておらず、候補の1つとして、ステップが残していったプロセスを挙げています。

• 上限を変える前に、最後のステップで動いているものを並べてください（Linux と macOS なら ps -ef）。
• background: true のステップは、後処理の前に待たれます（暗黙の wait-all）。そうして起動したサーバーは、終わるか止められるまでジョブを開いたままにします。cancel のステップで止めてください：

steps:
  - name: Start the server
    id: server
    run: ./scripts/serve.sh
    background: true
  - name: Run the tests
    run: npm test
  - name: Stop the server
    cancel: server

どうするか

• キャンセルされたときに動いていたステップを探す：

  gh api repos/OWNER/REPO/actions/jobs/JOB_ID --jq '.steps[] | select(.status != "completed") | .name'

• 上限を上げる前に、最近の成功した実行と比べる。あるプロジェクトのジョブは、真ん中の値で237秒、一番遅くて282秒で、上限は300秒でした。ランナーごとのふつうの差だけでもキャンセルされうる幅です（freenet-core #6095）。
• 長くなりうるステップに、ジョブより短い timeout-minutes を付ける。止まったステップが自分の名前の入ったメッセージで失敗し、if: always() のアップロードも動きます。
• 長い作業はマトリックスのジョブやシャードに分ける。noter #94 では、ある Windows のシャードが前の実行では63分、次の実行では90分を超え、ほかの Windows のシャードは33〜65分でした。
• 遅いランナーに一度当たっただけなら、Re-run failed jobs（または gh run rerun <run-id> --failed）。
• 6時間を超える作業には、セルフホストのランナーを使う。

ほかのキャンセルされたジョブ

• どのランナーもジョブを受け取らなかった：ステップ無しで約15分後にキャンセル（「The job was not acquired by Runner of type hosted」）。
• 同じ concurrency のグループに新しい実行が来た：「Canceling since a higher priority waiting request」（プルリクのチェックがキャンセルされた）。
• ランナー自体が止まった：ジョブは「The runner has received a shutdown signal」で失敗し、if: always() のステップも飛ばされます（どうするか）。
• だれかが実行をキャンセルした、または止まらない：止まらない実行と force-cancel。

キャンセルされたジョブとステップを 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 のいずれとも提携しておらず、承認も受けていません。上限は2026年11月3日の GitHub の文書によります。

ほかに：「The job was not acquired by Runner of type hosted」 · 「Waiting for a runner to pick up this job」 · デバッグログ付きでジョブを再実行する · IntelliJ IDEA で使える GitHub Actions のプラグインの比較 · English