Skip to main content

Kubernetes Pod Debugger

Enter your pod details and issue type. Get a step-by-step diagnostic command sequence, what to look for in each output, and common fix commands.

✓ Diagnostic command sequence ✓ What to look for per command ✓ Common fix commands ✓ CrashLoopBackOff / OOMKilled / ImagePullBackOff / Pending

Pod Details

Frequently Asked Questions

What causes CrashLoopBackOff?▼

CrashLoopBackOff means the container keeps starting and crashing. Kubernetes backs off between restarts (1s, 2s, 4s... up to 5 minutes). Common causes: application error on startup (bad config, missing env var), failed health check, out-of-memory kill (OOMKilled), or trying to bind to an already-used port. Check 'kubectl logs' and 'kubectl describe pod' for the exit code and last error.

Why is my pod stuck in Pending?▼

Pending means Kubernetes can't schedule the pod. Common causes: insufficient CPU/memory on all nodes (FailedScheduling), PodDisruptionBudget blocking, taint/toleration mismatch (NoSchedule), NodeAffinity/NodeSelector not matching any node, or PVC not bound (no storage class). Check 'kubectl describe pod' for the Events section which usually identifies the exact reason.

What is ImagePullBackOff vs ErrImagePull?▼

ErrImagePull is the initial failure when Kubernetes can't pull a container image. ImagePullBackOff is the retry state with exponential backoff. Causes: typo in image name, private registry without imagePullSecrets, rate limiting (Docker Hub), or deleted image tag. Fix by checking the image name, adding imagePullSecrets for private registries, or using a specific tag instead of latest.

How do I get logs from a crashed container?▼

For a crashed/restarted container, use 'kubectl logs <pod> --previous' (-p) to get the logs from the last terminated container instance. Without --previous you get current instance logs (which may be empty if it just started). For multi-container pods, add '-c <container-name>' to target a specific container.

What is OOMKilled and how do I fix it?▼

OOMKilled (exit code 137) means the container exceeded its memory limit and was killed by the Linux OOM killer. Fix: either increase the memory limit in your resource spec (limits.memory), or optimize your application's memory usage. Use 'kubectl top pods' to see actual memory usage and set your limit to at least 2× the observed peak. Check for memory leaks with profiling tools.

How do I exec into a running pod for debugging?▼

Use 'kubectl exec -it <pod-name> -- /bin/sh' (or /bin/bash for bash). For pods without a shell (distroless), use 'kubectl debug': it creates an ephemeral debug container with tools attached to the same pod. Always specify '-n <namespace>' if not in the default namespace.

Share this tool: X / Twitter LinkedIn
✓ 60,000+ developers use DevPlaybook ★★★★★ 4.8 / 5 on Gumroad ✓ MIT licensed · Instant download ✓ No login required

Related Products

on Gumroad

You Might Also Need

More Free Tools

Enjoying this tool? Get more like it.

Weekly developer tool guides, productivity playbooks & AI tricks. Free. No spam.

DevPlaybook Pro 7 days free

Unlock AI-Powered Dev Tools

  • ⚡ AI Code Review, Doc Generator & SQL Builder
  • ⚡ All premium templates & early access
  • ⚡ Member discounts on Gumroad products
Start Free Trial →

$9/mo after trial · Cancel anytime

Want the full toolkit?

Get DevPlaybook Pro

Every template, guide, boilerplate, and automation script in one bundle. 13 premium products — grab them all at once and save big.

$79
$241 separately Save $162 (67% off)
Get DevPlaybook Pro — $79 →

MIT licensed · Instant download · No subscription

See what's included → Browse all deals →