Docker "buildx failed with: ERROR: failed to build: failed to receive status"

By Kaveh Alemi·Latchkey

buildx lost its gRPC connection to the BuildKit daemon mid-build. The builder container crashed, was OOM-killed, or the connection dropped - so the client never received the final status.

What this error means

A docker buildx build (often via build-push-action) fails with failed to receive status: rpc error: code = Unavailable. It is frequently transient - re-running the job succeeds, which points at the builder dying rather than your Dockerfile.

ERROR: buildx failed with: ERROR: failed to build: failed to receive status:
rpc error: code = Unavailable desc = error reading from server: EOF

Diagnose it: build context, cache, or platform?

A Dockerfile that builds locally and fails in CI usually differs in one of three ways: the build context contains different files, the layer cache is cold or poisoned, or the runner architecture does not match what the base image provides.

# what is actually being sent as build context (dockerignore applies)
docker build --no-cache --progress=plain -t probe . 2>&1 | head -40

# what platform are you on, and what does the base image support?
docker version --format '{{.Server.Arch}}'
docker buildx imagetools inspect <base-image> | grep -i platform

# prove it is not a cache artefact
docker build --no-cache .

Common causes

The BuildKit builder was OOM-killed or crashed

A memory-heavy build exhausts the builder container’s memory and the daemon is killed, severing the gRPC stream. The client reports a lost status rather than the underlying OOM.

The builder container or runner was terminated

A runner running out of disk, a stopped builder container, or a runner reclaimed mid-job drops the connection to BuildKit.

Transient network blip to a remote builder

When using a remote/Kubernetes BuildKit driver, a brief network interruption between the client and the builder surfaces as Unavailable / EOF.

How to fix it

Recreate the builder and retry

Reset buildx to a fresh builder and re-run; a transient drop usually clears.

docker buildx rm mybuilder 2>/dev/null || true
docker buildx create --name mybuilder --use
docker buildx build .

Give the builder more headroom

1. Run the build on a larger runner if the builder is being OOM-killed.
2. Reduce build parallelism or split heavy stages to lower peak memory.
3. Check df -h - a builder that fills the disk also drops the connection.

Keep the build context small and deterministic

• A missing .dockerignore sends node_modules, .git, and build output to the daemon, which is slow and can change layer hashes between environments.
• A COPY of a path that exists locally but is gitignored will fail in CI, because the runner only has what the checkout produced.
• Multi-arch builds need buildx and QEMU set up explicitly; a plain docker build on an ARM runner silently produces an ARM image.

How to prevent it

• Right-size runners for memory- and disk-heavy buildx jobs.
• Pin and reuse a named builder rather than recreating it every step.
• Wrap remote-builder builds in a bounded retry for transient drops.

Frequently asked questions

Related guides

References

• Docker documentation
• Docker build cache
• GitHub Actions documentation