Confirm the workload and context
Name the cluster context, namespace, pod and container before collecting evidence. Multi-cluster environments often reuse workload names, so an implicit context is an avoidable source of mistakes.
Check whether all replicas are affected and whether the failure started during a rollout. A single failing replica and a deployment-wide regression point to different investigation paths.
Read the previous container logs
The current container may not have lived long enough to produce useful output. Previous logs can preserve the last run’s startup error, dependency failure or shutdown message. Inspect the specific container when a pod contains more than one.
Keep the log window small and avoid copying secrets into an investigation. Look for a concrete failure that explains the exit, rather than treating the last warning as the cause.
Compare termination state and events
Inspect the last termination reason and exit code, then read the pod events. OOMKilled is a different lead from an invalid configuration, an executable error or a liveness probe that keeps killing a slow-starting process.
Check resource limits, probe timing and referenced configuration. If memory is involved, compare workload behavior and node capacity before proposing a larger limit. A memory leak may simply take longer to fail after an increase.
Review recent changes
Compare the failing revision with the last known healthy one. Consider image references, environment variables, configuration mounts, secret availability and dependencies. Treat the time correlation as a lead that still needs supporting evidence.
A rollback must account for database migrations and external state. Reverting a deployment manifest does not necessarily reverse everything the newer application changed.
Change the smallest useful thing
Write down the target, proposed change, expected result and recovery condition. Review the plan, then apply it through your approved change process.
Watch rollout status, readiness, restarts and actual service behavior over a useful observation window. A successful rollout is a milestone; stable application behavior is the outcome. The Loggs homepage includes a fictional memory-limit scenario that demonstrates this review flow without touching a cluster.
Further reading
Consult the documentation for your installed version and review commands against your own environment.
Kubernetes: Debug Pods