How would your investigation differ if a Pod entered ImagePullBackOff instead of CrashLoopBackOff?

CrashLoopBackOff means the container's image was pulled successfully and the container did start, but its process kept exiting (crashing) — the investigation focuses on the application's own runtime behavior (logs, exit code, config). ImagePullBackOff means the container never even started at all, because Kubernetes couldn't successfully pull the specified image — the investigation focuses entirely on image reference correctness and registry access, since the application code itself never even got a chance to run.

These two states occur at genuinely different points in a Pod's startup sequence, which is exactly why the investigation differs completely.

ImagePullBackOff means the kubelet attempted to pull the container's image and failed, and is now backing off before retrying. The container process never started at all — there's no application log to check, because no application code ever ran. Common causes are entirely about the image reference and access, not application behavior: a typo in the image name or tag, an image that genuinely doesn't exist at that tag, a private registry requiring authentication that isn't configured (imagePullSecrets missing or incorrect), or a registry that's unreachable from the node (network/firewall issue). The investigation tools are correspondingly different: kubectl describe pod shows the specific pull error message (often naming the exact reason — "not found," "unauthorized," "manifest unknown"), and the fix is almost always correcting the image reference or the registry credentials, not anything about the application's own code.

CrashLoopBackOff means the image was pulled successfully and the container process did start, but it exited (crashed, or exited cleanly but unexpectedly) repeatedly, and Kubernetes is backing off between restart attempts. Since the application code did run, kubectl logs (including --previous to see the crashed instance's logs, since the current attempt may not have logged anything yet) is the primary tool — the investigation is about why the application itself is failing to stay running: a startup configuration error, a missing required environment variable or secret, a failing health check misconfigured to kill the process, or a genuine application bug.

The practical distinguishing signal, if you only have kubectl get pods output and no other context: ImagePullBackOff (or its close cousin ErrImagePull) tells you immediately to look at the image/registry, not application logs (which won't exist yet); CrashLoopBackOff tells you the opposite — the image and pull mechanics are fine, and the problem is entirely in what happens once the container's process actually starts running.

• ImagePullBackOff means the container never started — the image pull itself failed, and the investigation is entirely about the image reference and registry access.
• CrashLoopBackOff means the container did start but the process kept exiting — the investigation is entirely about application runtime behavior via logs and exit codes.
• kubectl logs --previous is the key tool for CrashLoopBackOff (seeing the crashed instance's output); it's irrelevant for ImagePullBackOff, since no application logs exist yet.
• The Pod status itself tells you which half of the startup sequence failed, directly pointing at where to start investigating.

• Kubernetes Docs: Debug Pods
• Kubernetes Docs: Images — image pull policy and troubleshooting