Docker "buildx failed with: ERROR: failed to build: failed to receive status"
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: EOFCommon 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
- Run the build on a larger runner if the builder is being OOM-killed.
- Reduce build parallelism or split heavy stages to lower peak memory.
- Check
df -h- a builder that fills the disk also drops the connection.
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.