GitHub Actions "The operation was canceled" - Why Jobs Get Cancelled

By Kaveh Alemi·Latchkey

The operation was canceled is a symptom, not a root cause. The job was stopped from outside - by a timeout, a concurrency rule, a lost runner, or a manual cancel. The fix depends entirely on which one.

What this error means

A job or step ends with The operation was canceled and no application error. The work was interrupted externally rather than failing on its own. Identifying the trigger is the whole job.

##[error] The operation was canceled.

Common causes

A timeout cancelled the job

When timeout-minutes (or the default limit) is reached, the runner cancels the operation. Look for a preceding "exceeded the maximum execution time" message.

Concurrency cancelled an older run

A concurrency group with cancel-in-progress: true cancels superseded runs when a newer commit arrives. The cancel is intentional, not a failure.

The runner was lost or preempted

If a runner crashes, loses network, or a spot/preemptible instance is reclaimed, the orchestrator marks the job canceled. A retry on a healthy runner succeeds.

How to fix it

Identify the trigger

1. Check for an "exceeded the maximum execution time" line just before the cancel - that means a timeout.
2. Check whether a newer run for the same concurrency group started - that means intentional cancellation.
3. Check whether the runner went offline (lost/preempted) - that is transient and retry-recoverable.

Act on the real cause

1. Timeout: speed up the job or raise the bounded timeout.
2. Concurrency: this is expected; no fix needed unless the policy is wrong.
3. Lost/preempted runner: retry the job, ideally on more stable capacity.

How to prevent it

• Set explicit timeouts so the cancel reason is unambiguous.
• Use concurrency deliberately and document the cancel-in-progress intent.
• Prefer stable capacity for jobs that must not be preempted.

Frequently asked questions

Related guides

References

• GitHub Actions documentation