ImagePullBackOff: Kubernetes could not pull the container image and is backing off before retrying

ImagePullBackOff means the kubelet tried to pull your image, failed, and is now waiting before trying again. The underlying failure is reported first as ErrImagePull, and the reason appears in the pod's events.

Applies to: All Kubernetes versions, any container runtime

What it means

When the kubelet cannot pull an image it first reports ErrImagePull. After repeated failures it applies a back-off delay and the status becomes ImagePullBackOff. The two are the same problem at different stages, and neither says why the pull failed — that detail is in the pod events. The distinction matters because the fix depends entirely on the reason: a typo in the tag, a private registry with no credentials, a rate limit, and a network path that cannot reach the registry all produce the same pod status but need completely different responses.

Most common causes

• The image name or tag is wrong, or the tag was deleted from the registry.
• The image is in a private registry and the pod has no imagePullSecrets, or the secret is in a different namespace than the pod.
• Docker Hub anonymous rate limits have been hit, which produces toomanyrequests in the event message.
• The node cannot reach the registry at all — a network policy, a firewall, an egress proxy, or missing DNS on the node.
• The image exists but is built for a different architecture than the node, for example an amd64 image on an arm64 node.
• imagePullPolicy: Always is set and the registry is temporarily unavailable, so a previously working pod suddenly cannot start.

How to diagnose it

1. Read the events, which contain the actual registry error: kubectl describe pod POD and look at the bottom of the output.
2. Match the message to the cause. manifest unknown or not found means the name or tag is wrong. unauthorized or authentication required means credentials. toomanyrequests means rate limiting. A timeout or no such host means the node cannot reach the registry.
3. Confirm the image reference actually exists: docker manifest inspect IMAGE:TAG from a machine that can reach the registry.
4. If credentials are involved, check the secret exists in the pod's own namespace: kubectl get secret -n NAMESPACE. Image pull secrets are namespaced and are not inherited across namespaces.
5. For architecture mismatches, compare the image's platforms with the node: kubectl get node NODE -o jsonpath='{.status.nodeInfo.architecture}'.

How to fix it

1. Correct the image name or tag in the pod spec. Avoid :latest in anything you intend to debug later, since it makes the failing version ambiguous.
2. For a private registry, create a docker-registry secret in the pod's namespace and reference it under imagePullSecrets, or attach it to the service account the pod uses.
3. For Docker Hub rate limits, authenticate even for public images, or mirror the image into a registry you control.
4. For unreachable registries, check node egress, DNS, and any proxy configuration on the container runtime rather than anything inside Kubernetes.
5. For architecture mismatches, build a multi-architecture image or pin the workload to matching nodes with a node selector.

Notes

A pod stuck here will never recover on its own if the cause is a typo or a missing secret — the back-off continues indefinitely. Fixing the spec or the secret and letting the pod be recreated is required.

Related

• ErrImagePull — The first failed image pull, before back-off begins

Sources

• Kubernetes documentation — Images
• Kubernetes documentation — Pull an Image from a Private Registry
• Kubernetes documentation — Debug Pods