Five Checks to Run Before Restarting a Failing Kubernetes Pod

When a Kubernetes pod fails in production, the instinct to restart it immediately can erase valuable diagnostic evidence. Engineers are advised to first run 'kubectl describe pod' to review container state, restart count, termination reasons, probe failures, and events. If the container has previously crashed, fetching logs from the prior instance using the '--previous' flag can reveal causes like OOMKilled errors, which may indicate a memory leak, misconfigured limits, or node pressure rather than simply requiring a higher memory ceiling. Probe misconfigurations — readiness, liveness, or startup — can also trigger incidents even when the underlying application is healthy. A structured approach of observing, capturing, and isolating the failure before applying a fix helps prevent the same incident from recurring.