GitHub Actions · Checked November 3, 2026

GitHub Actions: "The operation was canceled"

The step that was running was stopped from outside the job. The log ends with this line and nothing more:

##[error]The operation was canceled.

It says what happened to the step, not why. The reason is in a second annotation on the same job, and the fix depends on which one it is.

Where to read the reason

Open the run's summary page and look at the Annotations box, or ask the API for the cancelled jobs and their annotations (a job's id is also its check run's 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'

The quotes below are annotations from public jobs between October 23 and November 3, 2026.

The five reasons

1. A newer run in the same concurrency group

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

The workflow has a concurrency group, and a newer run joined it. That job was building with group: ci-docs-${{ github.ref }} and cancel-in-progress: true, so the next push to main stopped it. Jobs that were still waiting get only the first line and have no runner and no steps.

Without cancel-in-progress, a running job is left alone, but a waiting one is still replaced: by default a group holds one running and one pending job, and a newer one cancels the pending one. Group names are shared by every workflow in the repository, so two workflows with the same group name cancel each other (GitHub's concurrency documentation, November 3, 2026).

• Let pull requests cancel their older runs but never a push to the default branch:

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

• For deployments that must all run, one at a time, let up to 100 runs wait instead of replacing each other (it cannot be combined with cancel-in-progress: true):

  concurrency:
    group: production-deploy
    queue: max

Nothing needs re-running here: the newer run does the work. If a required check on a pull request shows as cancelled, see cancelled checks on a pull request.

2. Another job in the matrix failed

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

strategy.fail-fast defaults to true: when one job of a matrix fails, GitHub cancels the others that are running or queued. The run ends as Failure, and the cancelled jobs tell you nothing; read the job named in quotes. To let the other jobs finish, set fail-fast: false, or put continue-on-error: true on the matrix entries that are allowed to fail.

3. Someone cancelled the run

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

A person cancelled it from the Actions page, with gh run cancel, or through the API, and the annotation names the account. In one project, four runs on main were cancelled on October 29, and the issue suspected the concurrency settings; the annotations on those jobs named a person (harmflow-app #483). Read this one before changing the workflow. If a run will not stop when you cancel it, see cancelling a run that will not stop.

4. The job ran past its time limit

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

The job's timeout-minutes (360 minutes if not set) ran out. The job ends as Cancelled, not as timed out, so a script that retries only failed or timed-out jobs skips it (codex-skills #2624). What to look for and what still runs: "The job has exceeded the maximum execution time".

5. The runner stopped

The job fails, sometimes with only "The operation was canceled." or "Process completed with exit code 143." as its annotation, and the log ends with "The runner has received a shutdown signal". On GitHub's hosted runners that is usually memory: what to do.

Not this message: a step's own time limit

timeout-minutes on a step fails that step instead, and the job ends as Failure:

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

Steps after it run only if their if: allows a failure, such as if: always().

Re-running

• Re-run a time limit or a lost runner, after fixing what made the job slow or heavy.
• A concurrency cancel was replaced by a newer run, and a fail-fast cancel goes away when the failed job is fixed; re-running those only repeats work.
• To re-run one job: Re-run jobs on that job, or gh run rerun RUN_ID --job JOB_ID.

See cancelled jobs from IntelliJ IDEA

Pipeline Inbox for GitHub Actions Workflows, a plugin by Lesstep for JetBrains IDEs 2024.1 or later, lists the runs of all your repositories in an IDE tool window, with their jobs and steps, so you can see which job failed and which ones were only cancelled, and your current branch's runs are in the status bar. Reading is free; re-running failed jobs, cancelling, running workflows and reviewing deployments are Pro (US$1.50 a month, with a 30-day trial).

GitHub and GitHub Actions are trademarks of GitHub, Inc.; IntelliJ IDEA is a trademark of JetBrains s.r.o. This page is not affiliated with, sponsored or endorsed by GitHub, Inc. or JetBrains.

More: "The job has exceeded the maximum execution time" · "The runner has received a shutdown signal" · Cancelling a run that will not stop · GitHub Actions plugins for IntelliJ IDEA compared · 日本語