Docker: context canceled — build or pull interrupted mid-operation
context canceled — operation interrupted
Verified against Docker Desktop release notes — resource management, Go standard library: context package documentation, Moby GitHub issues: context canceled reports · Updated June 2026
> quick_fix
Docker canceled the operation before it finished. Common causes: low disk space, unstable network during pull, Docker Desktop running out of memory, or the build exceeding a CI timeout. Free disk space with docker system prune, check your network, and retry.
# Check disk space used by Docker
docker system df
# Free unused images, containers, volumes
docker system prune -a --volumes
# Retry the build with no cache
docker build --no-cache -t myapp .What causes this error
The 'context canceled' error in Docker means the Go context that governs an operation (build step, image pull, container start) was canceled before completion. In Go's concurrency model, a context carries deadlines and cancellation signals. When Docker's daemon or CLI cancels the context — due to timeout, resource exhaustion, user interrupt (Ctrl+C), or a failed health check — all in-flight operations attached to that context abort with this error. It's not a Docker-specific error code; it's Go's standard cancellation mechanism surfacing through Docker's error reporting.
How to fix it
- 01
step 1
Check available disk space
The most common cause is Docker running out of disk. Run docker system df to see how much space images, containers, and volumes consume. If usage is high, run docker system prune to reclaim space.
docker system df # If reclaimable is high: docker system prune -a --volumes - 02
step 2
Check Docker Desktop resource limits
On Mac/Windows, Docker Desktop has memory and CPU limits in Settings → Resources. If your build needs more RAM (common with large npm install or compilation steps), increase the memory allocation and restart Docker Desktop.
- 03
step 3
Check network stability for pulls
If the error happens during docker pull or a FROM instruction, your network may be dropping the connection. Try pulling the base image separately first: docker pull node:20. If it fails, check your DNS, proxy settings, or VPN.
- 04
step 4
Increase CI timeout if applicable
In CI systems (GitHub Actions, GitLab CI), builds have a default timeout. If your build is legitimately slow, increase the timeout in your CI config rather than optimizing under pressure.
- 05
step 5
Retry with --no-cache
A corrupted build cache can cause context cancellation mid-build. Retry with docker build --no-cache to bypass cached layers.
How to verify the fix
- docker build completes without 'context canceled' errors.
- docker system df shows adequate free space.
- The built image runs correctly with docker run.
Why context canceled happens at the runtime level
Docker is written in Go, and Go's context.Context is the standard mechanism for propagating cancellation, deadlines, and request-scoped values across goroutine boundaries. When you run docker build, the CLI creates a context and passes it through every operation: pulling base images, executing RUN instructions, copying files. If any parent in the call chain cancels the context (the daemon hitting a resource limit, the CLI receiving SIGINT, a CI runner killing the process), every child operation receives the cancellation signal and returns context.Canceled. The error message 'context canceled' is the string representation of Go's context.Canceled sentinel error — it's not Docker-specific, which is why it's confusing to developers who don't know Go internals.
Common debug mistakes for context canceled
- Assuming the error is network-related when it's actually disk space — 'context canceled' during a pull looks like a network timeout but is often the Docker daemon aborting because it can't write the pulled layers to disk.
- Running docker system prune without --volumes and wondering why space wasn't freed — dangling volumes can consume tens of GB and prune skips them by default.
- Increasing Docker Desktop memory to fix a build that's genuinely leaking memory in a RUN step — the build step itself (e.g. webpack, tsc) may have a memory leak; more RAM delays the crash but doesn't fix it.
- Retrying the same build in CI without investigating — if the CI runner is resource-constrained, retries just burn compute credits without fixing anything.
When context canceled signals a deeper problem
Frequent 'context canceled' errors in a Docker workflow usually indicate the build has outgrown its resource envelope. This happens naturally as projects add dependencies and the build cache grows. The deeper fix is build optimization: multi-stage builds that separate dependency installation from application code, .dockerignore files that exclude node_modules and build artifacts from the build context, and layer ordering that maximizes cache hits. A well-structured Dockerfile that separates COPY package*.json and RUN npm install from COPY . prevents re-downloading all dependencies on every code change — reducing build time, memory usage, and the probability of context cancellation.
Editor's take
The worst 'context canceled' incident I've seen was a team running docker build in GitHub Actions with a 2GB build context because they forgot to add node_modules to .dockerignore. The build context upload alone took 4 minutes, and the actual build consumed so much memory copying files that the runner's OOM killer terminated the Docker daemon mid-layer. The error said 'context canceled' with no mention of memory — the team spent two days blaming their network and Docker Hub rate limits before someone ran docker build with DOCKER_BUILDKIT=1 and saw the real build context size in the output.
Knowing that 'context canceled' is a Go context error (not a Docker-specific error) is the insight that lets you debug it systematically. The Go context package has exactly two failure modes: Canceled (something called cancel()) and DeadlineExceeded (a timeout fired). If you see 'context canceled' and not 'deadline exceeded', something actively killed the operation — not a timeout. That narrows your search to: resource exhaustion, user interrupt, or parent process death.
In the same session you'll often find: 'no space left on device' if the disk was the bottleneck, 'error creating overlay mount' if the Docker storage driver hit corruption from a previous canceled build, and 'connection reset by peer' if a registry pull was interrupted mid-transfer.
By Bikram Nath · Curator · Updated June 2026
Frequently asked questions
Is 'context canceled' the same as 'context deadline exceeded'?
No. 'context canceled' means something actively canceled the operation (user interrupt, resource limit, parent process exit). 'context deadline exceeded' means a timeout was reached. Both are Go context errors, but the causes differ — canceled is usually resource/interrupt, deadline is timeout.
Why does this happen more on Mac than Linux?
Docker Desktop on Mac runs inside a Linux VM with fixed memory/CPU limits. On Linux, Docker runs natively with access to all system resources. Mac users hit resource ceilings faster, especially during multi-stage builds with heavy compilation steps.