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

GitHub Actions：「The operation was canceled」

動いていたステップが、ジョブの外から止められたという意味です（「操作はキャンセルされた」）。ログはこの1行で終わり、その先はありません：

##[error]The operation was canceled.

ステップに何が起きたかは書かれていますが、なぜかは書かれていません。理由は同じジョブのもう1つの注釈にあり、直し方はそれで決まります。

理由の見方

実行のまとめのページの Annotations の欄を見るか、API でキャンセルされたジョブとその注釈を引きます（ジョブの id はそのチェックランの id と同じです）：

gh run view RUN_ID --repo OWNER/REPO --json jobs --jq '.jobs[] | select(.conclusion == "cancelled") | .databaseId'
gh api repos/OWNER/REPO/check-runs/JOB_ID/annotations --jq '.[].message'

下に引く文は、2026年10月23日〜11月3日の公開のジョブの注釈です。

5つの理由

1. 同じ concurrency のグループに新しい実行が来た

Canceling since a higher priority waiting request for ci-docs-refs/heads/main exists
The operation was canceled.

ワークフローに concurrency のグループがあり、そこに新しい実行が入りました。このジョブは group: ci-docs-${{ github.ref }} と cancel-in-progress: true でビルドしていたので、main への次のプッシュで止まりました。まだ待っていたジョブには1行目だけが付き、ランナーもステップもありません。

cancel-in-progress が無ければ、動いているジョブはそのままですが、待っているジョブはやはり入れ替わります。既定では、1つのグループに置けるのは動いているジョブ1つと待っているジョブ1つで、新しいものが待っている方をキャンセルします。グループの名前はリポジトリのすべてのワークフローで共通なので、同じ名前のグループを持つ2つのワークフローは互いをキャンセルします（2026年11月3日の GitHub の concurrency の文書）。

プルリクでは古い実行をキャンセルし、既定のブランチへのプッシュは決してキャンセルしない：

concurrency:
  group: ci-${{ github.event.pull_request.number || github.sha }}
  cancel-in-progress: ${{ github.event_name == 'pull_request' }}

全部を1つずつ動かしたいデプロイでは、入れ替えずに最大100本まで待たせる（cancel-in-progress: true とは一緒に使えません）：
```
concurrency:
  group: production-deploy
  queue: max
```

ここで再実行は要りません。新しい実行が同じ仕事をします。プルリクの必須のチェックがキャンセルと出ているなら、プルリクでキャンセルされたチェックを見てください。

2. マトリックスの別のジョブが失敗した

The strategy configuration was canceled because "build.linux_amd64_linux-amd64_b" failed
The operation was canceled.

strategy.fail-fast の既定は true で、マトリックスのジョブが1つ失敗すると、GitHub は動いているか待っている残りのジョブをキャンセルします。実行は Failure で終わりますが、キャンセルされたジョブを見ても何も分かりません。引用符の中の名前のジョブを読んでください。残りのジョブを最後まで動かすなら fail-fast: false にするか、失敗してよいマトリックスの組み合わせに continue-on-error: true を付けます。

3. だれかが実行をキャンセルした

The run was canceled by @USERNAME.
The operation was canceled.

人が Actions のページ・gh run cancel・API のどれかでキャンセルし、注釈にそのアカウントが出ます。あるプロジェクトでは、10月29日に main の実行が4本キャンセルされ、issue では concurrency の設定が疑われていましたが、そのジョブの注釈には人の名前が出ていました（harmflow-app #483）。ワークフローを変える前に、まずこれを読んでください。キャンセルしても止まらない実行は、止まらない実行のキャンセルを見てください。

4. ジョブが時間の上限を超えた

The job has exceeded the maximum execution time of 25m0s
The operation was canceled.

ジョブの timeout-minutes（書かなければ360分）が尽きました。ジョブは「時間切れ」ではなく Cancelled で終わるので、失敗か時間切れのジョブだけを再実行するスクリプトはこれを飛ばします（codex-skills #2624）。何を探すか、何がまだ動くかは「The job has exceeded the maximum execution time」にあります。

5. ランナーが止まった

ジョブは失敗になり、注釈が「The operation was canceled.」か「Process completed with exit code 143.」だけのこともあり、ログは「The runner has received a shutdown signal」で終わります。GitHub のホストのランナーでは、たいていメモリです：どうするか。

この行ではないもの：ステップ自身の時間の上限

ステップの timeout-minutes では、そのステップが失敗になり、ジョブは Failure で終わります：

The action 'Build MKL-free CPU torch' has timed out after 310 minutes.

後ろのステップは、if: always() のように失敗の後でも動く if: のものだけが動きます。

再実行

時間の上限とランナーの停止は、ジョブを遅く重くした原因を直してから再実行します。
concurrency のキャンセルは新しい実行に置き換わっていて、fail-fast のキャンセルは失敗したジョブを直せば消えます。どちらも再実行すると同じ仕事を繰り返すだけです。
ジョブを1つだけ再実行するには、そのジョブの Re-run jobs、または gh run rerun RUN_ID --job JOB_ID。

キャンセルされたジョブを 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 job has exceeded the maximum execution time」 · 「The runner has received a shutdown signal」 · 止まらない実行のキャンセル · IntelliJ IDEA で使える GitHub Actions のプラグインの比較 · English