Troubleshooting Kubernetes ImagePullBackOff and ErrImagePull Errors

What Are ErrImagePull / ImagePullBackOff Errors?

ErrImagePull and ImagePullBackOff are Kubernetes errors caused by failure to pull a container image from a container registry. 

When a Kubernetes cluster creates a new deployment, or updates an existing deployment, it typically needs to pull an image. This is done by the kubelet process on each worker node. For the kubelet to successfully pull the images, they need to be accessible from all nodes in the cluster that match the scheduling request. When sometimes goes wrong, you can experience one of these errors:

• The ImagePullBackOff error occurs when the image path is incorrect, the network fails, or the kubelet does not succeed in authenticating with the container registry.
• Kubernetes initially throws the ErrImagePull error, and then after retrying a few times, “pulls back” and schedules another download attempt. For each unsuccessful attempt, the delay increases exponentially, up to a maximum of 5 minutes.

This is part of a series of articles about Kubernetes troubleshooting.

TL;DR: Fix ErrImagePull / ImagePullBackOff Fast

These errors mean kubelet can’t pull your container image, so the Pod stays stuck until the pull succeeds.

Fastest command path

• kubectl describe pod <pod> -n <ns> (check Events)
• Confirm the image reference in the manifest (name + tag/digest + registry)

Most common root causes

• “Manifest not found”: wrong tag/digest (or missing latest)
• “no pull access / authorization failed”: missing/incorrect registry credentials (Secret)
• “i/o timeout / TLS handshake timeout”: registry reachability (DNS/network/firewall)

Prevention teaser

• Pin image digests, validate image names/tags in CI, and monitor pulls to catch failures before they cascade.

Fast Diagnosis

If Events say Manifest ... not found → tag/digest issue

• Fix the tag/digest in the Pod spec; verify the tag exists; don’t assume latest exists.

If Events say Repository ... does not exist or no pull access or authorization failed → creds/Secret issue

• Confirm the image is in the right registry + repo, then configure imagePullSecrets with valid permissions.

If Events show timeouts (e.g., i/o timeout, TLS handshake timeout) → registry/network/DNS issue

• Validate node egress + DNS resolution to the registry; check firewall/proxy rules.

ImagePullBackOff and ErrImagePull Errors: Common Causes

Rate Limits & Registry Throttling

Image pulls can fail even when your image name, tag, and credentials are correct, because registries can throttle requests under fair-use or pull-rate rules. Docker Hub, in particular, applies pull rate limits for unauthenticated usage. Limits are enforced per IP/subnet, which can affect shared NAT’d clusters and CI runners.

If you’re pulling from Docker Hub unauthenticated, rate limits can trigger intermittent pull failures. Docker documents pull usage and limits, including unauthenticated pull rate limits and fair-use throttling.

Authenticate pulls

• Ensure nodes/workloads pull as an authenticated user (for Kubernetes, this typically means valid registry credentials and correct imagePullSecrets wiring).

Use a registry mirror / cache

• Add a pull-through cache or mirror so repeated pulls come from your internal network instead of hammering Docker Hub.

Pre-pull on nodes for bursty rollouts

• Warm nodes ahead of a large rollout (common patterns: a DaemonSet “pre-puller” job, or node image preloading in your AMI/base image process).

Reduce parallelism during deploy storms

• Tune rollout behavior so you don’t trigger a pull stampede (for Deployments, review maxSurge, maxUnavailable, and cluster autoscaling bursts).

If this is happening across multiple services or clusters, an AI SRE workflow can help correlate where throttling occurs and what changed before it started. If you’re seeing repeated pull retries during rollouts, that churn can inflate infra costs, so connect it to your Kubernetes cost optimization guidance.

How Does Kubernetes Work with Container Images?

A container image includes the binary data of an application and its software dependencies. This executable software bundle can run independently and makes well-defined assumptions about its runtime environment. You can create an application’s container image and push it to a registry before you refer to it in a pod.

A new container image typically has a descriptive name like kube-apiserver or pause. It can also include a registry hostname, such as test.registry.sample/imagename, and a port number, such as test.registry.sample:10553/imagename. Note that when you do not specify a registry hostname, Kubernetes assumes you refer to the Docker public registry.

After naming the image, you can add a tag to identify different versions of the same series of images.

What Happens During an ImagePullBackOff?

When a Kubernetes pod is in the ImagePullBackOff state, it means Kubernetes has encountered repeated issues while trying to pull the specified container image. This error arises during the image retrieval process, which involves multiple steps:

1. Resolving the Image Path: Kubernetes parses the image name provided in the pod specification. If the name is incomplete, misspelled, or refers to an unqualified registry, the kubelet may fail to locate the image.
2. Connecting to the Registry: Kubernetes attempts to connect to the specified container registry. Network issues, DNS misconfigurations, or firewalls blocking access can prevent a successful connection.
3. Authenticating with the Registry: For private registries, Kubernetes requires credentials stored in a Secret to authenticate. If these credentials are missing, misconfigured, or incorrect, the kubelet cannot pull the image.
4. Pulling the Image: Once authenticated, Kubernetes tries to download the image layers. If the image does not exist at the specified location or the tag is incorrect, the process fails.

When any of these steps fail, Kubernetes initially logs an ErrImagePull error. After multiple retries, Kubernetes increases the wait time exponentially between retries, eventually putting the pod into the ImagePullBackOff state. This behavior is intended to prevent excessive resource consumption while allowing administrators time to resolve the issue.

Tips from the expert

Itiel Shwartz

Co-Founder & CTO

Itiel is the CTO and co-founder of Komodor. He’s a big believer in dev empowerment and moving fast, has worked at eBay, Forter and Rookout (as the founding engineer). Itiel is a backend and infra developer turned “DevOps”, an avid public speaker that loves talking about things such as cloud infrastructure, Kubernetes, Python, observability, and R&D culture.

In my experience, here are tips that can help you better manage and resolve ErrImagePull and ImagePullBackOff errors in Kubernetes:

Specify image digests

Use image digests instead of tags to ensure consistency and avoid issues with tag changes.

Authenticate with registries

Ensure your Kubernetes nodes are properly authenticated to pull from private registries.

Use multi-arch images

For heterogeneous clusters, use multi-architecture images to avoid compatibility issues.

Implement retries

Configure retry policies and backoff strategies for pulling images.

Monitor registry health

Regularly check the health and performance of your container registry to prevent downtime.

How to Troubleshoot and Fix ImagePullBackOff and ErrImagePull Errors

As mentioned, an ImagePullBackOff is the result of repeat ErrImagePull errors, meaning the kubelet tried to pull a container image several times and failed. This indicates a persistent problem that needs to be addressed.

Step 1: Gather information

Run kubectl describe pod [name] and save the content to a text file for future reference:

kubectl describe pod [name] /tmp/troubleshooting_describe_pod.txt

Step 2: Examine Events section in describe output

Check the Events section of the describe pod text file, and look for one of the following messages:

• Repository ... does not exist or no pull access
• Manifest ... not found
• authorization failed

The image below shows examples of how each of these messages appears in the Events output.

Step 3: Troubleshoot and resolve

If the error is Repository ... does not exist or no pull access:

• This means that the repository specified in the pod does not exist in the Docker registry the cluster is using
• By default, images are pulled from Docker Hub, but your cluster may be using one or more private registries
• The error may occur because the pod does not specify the correct repository name, or does not specify the correct fully qualified image name (e.g. username/imagename)

To resolve it, double check the pod specification and ensure that the repository and image are specified correctly.

If this still doesn’t work, there may be a network issue preventing access to the container registry. Look in the describe pod text file to obtain the hostname of the Kubernetes node. Log into the node and try to download the image manually.

If the error is Manifest ... not found:

• This means that the specific version of the requested image was not found.
• If you specified a tag, this means the tag was incorrect.

To resolve it, double check that the tag in the pod specification is correct, and exists in the repository. Keep in mind that tags in the repo may have changed.

If you did not specify a tag, check if the image has a latest tag. Images that do not have a latest tag will not be returned, if you do not specify a valid tag. In this case, you must specify a valid tag.

If the error is authorization failed:

• The issue is that the container registry, or the specific image you requested, cannot be accessed using the credentials you provided.

To resolve this, create a Secret with the appropriate credentials, and reference the Secret in the pod specification.

If you already have a Secret with credentials, ensure those credentials have permission to access the required image, or grant access in the container repository.

Solving Kubernetes Errors Once and for All With Komodor

Komodor is the Continuous Kubernetes Reliability Platform, designed to democratize K8s expertise across the organization and enable engineering teams to leverage its full value.

Komodor’s platform empowers developers to confidently monitor and troubleshoot their workloads while allowing cluster operators to enforce standardization and optimize performance. Specifically, Komodor isturns hours of guesswork into actionable answers in just a few clicks. Using Komodor, you can monitor, alert and troubleshoot ErrImagePull or ImagePullBackoff events (among all other issues that can – and will – occur!)

By leveraging Komodor, companies of all sizes significantly improve reliability, productivity, and velocity. Or, to put it simply – Komodor helps you spend less time and resources on managing Kubernetes, and more time on innovating at scale.

FAQs About ErrImagePull