A pod that restarts every few seconds can look like a single application bug, but Kubernetes failures often begin one layer away from the code. A bad command, an exhausted memory limit, a failing readiness probe, a missing Secret, or an unhealthy node can all produce similar symptoms. To debug Kubernetes pod crashes efficiently, start with the pod’s current state, then work outward through events, logs, configuration, and cluster conditions.
The goal is not to memorize every status code. It is to build a repeatable investigation that separates a failed process from a failed deployment, a failed dependency, or a failed runtime environment.
Start with the pod status and restart history
Run `kubectl get pods -n ` first, then inspect the affected workload with `kubectl describe pod -n `. The `describe` output is usually the fastest source of context because it combines container state, restart counts, mounted volumes, environment configuration, scheduling details, and recent events.
Pay close attention to `State`, `Last State`, `Reason`, `Exit Code`, and `Restart Count`. A pod in `CrashLoopBackOff` is not itself a root cause. It means Kubernetes repeatedly started the container, observed that it exited or failed, and is waiting progressively longer before trying again.
The exit code narrows the search. Exit code `1` commonly means the application returned an error. Exit code `137` often indicates the container was terminated after exceeding its memory limit, although it can also result from a forced kill. Exit code `143` generally means the process received a SIGTERM signal during a normal shutdown, rollout, eviction, or manual deletion.
A pod with a high restart count but a current `Running` status deserves attention too. It may have recovered from an intermittent database, DNS, or startup dependency failure. Production incidents are frequently hidden in those previous container states.
Read current and previous container logs
For a container that is still alive, use `kubectl logs -n `. If the pod includes sidecars, specify the target with `-c `. For a crashing container, the most useful command is often `kubectl logs -n –previous`.
The `–previous` flag retrieves logs from the last terminated container instance. Without it, you may see no output at all because Kubernetes has already started a new instance that has not reached the failing code path.
Look for the final meaningful error rather than the last line alone. A Java service may log a database authentication exception before the JVM exits. A Node.js service may reveal an unhandled promise rejection caused by a missing environment variable. A Python process may fail during import because the image contains an incompatible dependency version.
Logs are strongest when the process starts successfully and can report its own failure. They are less useful for immediate image startup problems, out-of-memory kills, and node-level disruptions. In those cases, Kubernetes events and resource data become more important.
Use events to identify deployment and scheduling failures
The Events section at the end of `kubectl describe pod` explains what Kubernetes attempted to do. It can expose problems that application logs never see: `FailedScheduling`, `FailedMount`, `ErrImagePull`, `ImagePullBackOff`, or failed Secret and ConfigMap references.
For a broader view, inspect namespace events in time order with `kubectl get events -n –sort-by=.lastTimestamp`. This matters when several pods fail at once. A single bad image tag tends to affect a new deployment revision. A node pressure event or unavailable storage system can affect unrelated workloads at the same time.
Treat the timing as evidence. If crashes began immediately after a Helm release, GitOps sync, image promotion, or configuration change, compare the new ReplicaSet or Deployment revision against the last known-good version. If there was no application change, investigate shared dependencies, node health, identity permissions, DNS, and cluster capacity before rewriting code.
Diagnose the most common crash patterns
CrashLoopBackOff: the process exits repeatedly
This is the broadest category. Confirm the container command and arguments first, especially when an image has an `ENTRYPOINT` that is overridden in the workload manifest. A shell syntax mistake, incorrect binary path, or command that completes successfully instead of running a long-lived service can all cause a loop.
Next, validate runtime configuration. Confirm that required environment variables exist, Secret keys match the expected names, ConfigMaps are mounted where the application expects them, and external endpoints are reachable from the namespace. A configuration value can be present but still wrong, such as a database hostname from another environment.
OOMKilled: memory limits are too low or usage is unbounded
When `Last State` reports `OOMKilled`, inspect the container’s memory request and limit alongside application behavior. Raising the limit may stop the immediate failure, but it is not always the correct fix. A genuine memory leak, oversized cache, runaway query, or concurrency spike can simply consume the larger allocation later.
Compare observed memory use with normal traffic patterns. If the workload needs a predictable baseline, adjust requests and limits based on measured usage. If consumption climbs continuously, profile the application and examine recent code changes. Also check whether a node-level out-of-memory condition triggered evictions across multiple pods, which is different from a container crossing its own cgroup limit.
Probe failures: Kubernetes kills an application that may be healthy enough
Liveness, readiness, and startup probes serve different purposes. A readiness failure removes a pod from Service endpoints but does not restart it. A liveness failure tells Kubernetes to restart the container. A startup probe delays liveness and readiness checks while slow-starting applications initialize.
A common mistake is using the same aggressive HTTP check for all three. A service that needs 90 seconds to load migrations, warm a cache, or establish a secure connection may fail liveness checks long before it is expected to serve traffic. Add or tune a startup probe, then set realistic initial delays, timeouts, periods, and failure thresholds.
Do not make probes so forgiving that they stop detecting real faults. The right values depend on startup characteristics, traffic behavior, and how quickly the application can recover.
Image and dependency failures: the container never gets far enough to log
`ImagePullBackOff` points to image names, tags, registry access, or image pull credentials. Verify the exact image reference generated by your deployment tooling. Mutable tags such as `latest` make this harder because the same manifest can produce different runtime behavior over time.
For private registries, confirm the image pull Secret exists in the pod’s namespace and is referenced by the ServiceAccount or workload. For applications that crash after pulling, verify architecture compatibility too. An image built for the wrong CPU architecture can fail before your application starts.
Check dependencies from inside the cluster
An application may crash because it cannot resolve a service name, authenticate to a cloud API, open a database connection, or retrieve a certificate. Testing from a developer laptop does not prove that the pod has the same network path, DNS configuration, identity, or network policy.
Use an ephemeral debug container or a temporary diagnostic pod in the same namespace to test DNS lookups, TCP connectivity, TLS certificates, and HTTP responses. This approach is safer than modifying the production image just to add troubleshooting tools.
If network policies are in use, inspect both ingress and egress rules. A policy that permits application traffic but blocks DNS, telemetry, or an external identity endpoint can create confusing startup failures. Similarly, cloud workload identity issues may appear as generic authentication errors until you inspect the service account annotations and projected credentials.
Know when the problem is not the pod
A pod is where the failure appears, not necessarily where it originates. Check node conditions with `kubectl get nodes` and inspect the node running the workload when events suggest memory pressure, disk pressure, PID pressure, or repeated kubelet errors.
Also review PersistentVolume claims when containers depend on mounted storage. A pod can remain pending because a volume cannot attach, or it can start and fail because the expected mount path is unavailable or read-only. For managed Kubernetes platforms, control plane events and cloud-provider audit logs may provide the missing context for load balancer, identity, or storage failures.
When multiple workloads fail together, resist the urge to debug each pod independently. Correlated failures are a strong signal of a shared platform dependency.
Make crashes easier to debug before the next incident
The best incident workflow starts before an incident. Emit structured logs to standard output, include request and correlation identifiers where appropriate, and make startup failures explicit. Record the application version, configuration revision, and environment in logs so operators can connect a crash to a deployment change quickly.
Set resource requests deliberately, use immutable image tags or digests for releases, and test probes under realistic startup and dependency conditions. Alert on restart-rate trends rather than only on a pod reaching a terminal state. A slowly increasing restart count can reveal instability before users notice it.
The practical habit is simple: read the pod state, capture previous logs, inspect events, validate the change, and then widen the investigation to dependencies and nodes. That sequence turns Kubernetes crashes from a noisy symptom into a tractable engineering signal.
