Pod & Container Failures
Detects abnormal pod and container terminations and keeps the logs, YAML, and timeline you need to find the cause.
The Pod restarts every 5 minutes, and kubectl get shows only CrashLoopBackOff
kubernetes.io, Pod Lifecycle and Assign Memory Resources to Containers and Pods; Komodor, 2025 Enterprise Kubernetes Report.
kubectl get pods shows CrashLoopBackOff, not the cause. The cause, such as OOMKilled, is in kubectl describe, and the log of the failed container is in kubectl logs --previous.
Between restarts the kubelet waits 10s, 20s, 40s, and so on, up to 5 minutes. By the time someone looks, the log of the container that failed is often gone.
A high-impact Kubernetes outage takes a median of 51 minutes to resolve, and 39% take an hour or more (Komodor, 2025 Enterprise Kubernetes Report).
Back-off: 10s, doubling, up to 5 minutes (kubernetes.io, Pod Lifecycle). Restart count is illustrative.
How Wave does it
Containergoes over its memory limit, or crashes- restart
kubeletrestarts it after 10s, 20s, 40s, up to 5 min - status
kubectl get podsshows CrashLoopBackOff, not the cause - by hand
Engineerruns kubectl describe and logs --previous
Wave Agentwith cAdvisor on every node, reports each state change- gRPCWave Corematches 11 failure types, no polling
- on failureEvidenceprevious log, pod.yaml, node.yaml, kept at failure time
- incidentWave Console48-hour heatmap and incident timeline
Detect 11 abnormal transitions
OOMKilled, CrashLoopBackOff, ContainerCrash, evictions, preemptions, and more, from the data Wave Agent already pushes. Nothing to enable per workload.
Keep the evidence
At the moment of failure, Wave keeps the previous container's log, pod.yaml, and node.yaml.
Show when it started
A 48-hour heatmap per workload, then an incident timeline with a plain-language explanation of what failed and what to check.