oxygen914/kubeoncall/pod-oom-triage

Pod OOMKilled Triage

Diagnostic objective

Distinguish a container limit breach from memory leak, traffic growth, oversized work, and node-wide memory pressure.

Required live evidence

Confirm termination reason, exit code, restarts, requests/limits, QoS, node MemoryPressure, events, previous logs, working set/RSS, traffic or queue, GC/heap signals, and release timing. Compare healthy replicas and node headroom.

Decision branches

• Usage reaches the container limit while node memory is healthy: compare stable working set and configured limit.
• Memory grows after a release: preserve trend and diagnostic artifacts; treat leak as a hypothesis until verified.
• Usage spikes with traffic or large work: correlate per-instance load and queue behavior.
• Kernel or node OOM affects several workloads: hand off to node-memory-pressure-triage.

Safe next step

Record the memory timeline and capacity evidence; propose any action separately.

Prohibited actions

Do not remove limits, restart or scale workloads, save sensitive heap dumps, or patch live Pods from this Skill.

Recovery and escalation

Require stable restarts, bounded memory, sufficient Ready replicas, normal errors, and no node MemoryPressure. Escalate for repeated multi-replica OOM, node OOM, or suspected sensitive-data exposure.