Investigate a crashing Kubernetes pod using logs and historical metrics

In SigNoz Cloud, you can investigate a container restart by comparing the pod's logs with its CPU and memory history around the failure. To make that comparison, use the Kubernetes integration to collect and send both logs and resource metrics before an incident. After the pod is deleted, the data will only be available if it reached SigNoz Cloud before deletion and is still within its retention period.

Compare the error with resource history

For example, take crashing-pod-demo, an app that writes regular progress logs. We set it to exit once with code 1, and Kubernetes restarted its container in the same pod. In Logs Explorer, find the pod's logs for the failure period and open the error. Select Metrics → Pod to compare the error with CPU and memory usage around that time.

The selected log says the app exits with code 1, and the later app_started log shows the app starting again. The CPU and memory charts give you context for investigating the restart.

The Pod view shows metrics around the selected log, matching them by cluster and pod name. A replacement pod can reuse that name, so its history may also appear. To focus on one pod instance or container, use Metrics Explorer to filter by the pod's unique ID (k8s.pod.uid) and container name when those attributes are available. If the log includes the pod UID, you can find it in the log details.

Check why the container stopped

Logs and resource history help narrow the cause, but a rise in memory alone does not prove an out-of-memory kill. Check the container's termination reason and exit code in Kubernetes while the pod is still available. Once the pod is deleted, its live Kubernetes status is no longer available.