CI "##[error]The operation was canceled" After a Timeout

By Daniel Zoghalchali·Latchkey

When ##[error]The operation was canceled follows a "maximum execution time" line, the cancellation was a timeout: the job ran past its allowed minutes and the runner stopped it. The cancel is the effect; the timeout is the cause.

What this error means

A job ends with ##[error]The operation was canceled, and just above it is a line about exceeding the maximum execution time. The job was still doing work - it was cut off at the limit, sometimes because a transient slowdown pushed an otherwise-fast job over.

The job running on runner ... has exceeded the maximum execution time of 60 minutes.
##[error]The operation was canceled.

Common causes

A transient slowdown pushed the job over the limit

Slow downloads, a congested runner, or a flaky dependency made a normally-fast job exceed its timeout. On a retry it finishes in time - the mechanical/transient case.

The timeout is genuinely too low

If the job legitimately needs more time than timeout-minutes allows, it hits the limit every run. That is a real config issue - raise the bound or speed the job up.

How to fix it

Set a realistic, explicit timeout

Bound the job so a hang fails fast but real work has headroom.

jobs:
  build:
    runs-on: ubuntu-latest
    timeout-minutes: 30

Make the job finish faster

1. Cache dependencies so installs do not dominate runtime.
2. Parallelize or shard long build/test steps.
3. Add per-step timeout-minutes so one slow step fails fast instead of consuming the whole budget.

How to prevent it

• Set explicit job and step timeouts rather than relying on the default.
• Cache and parallelize to keep runtimes well under the limit.
• Track job duration trends so a creeping slowdown is caught early.

Frequently asked questions

Related guides

References

• GitHub Actions documentation