How to Fix Kubernetes OOMKilled Exit Code 137 in Production

When a Kubernetes Pod terminates with Exit Code 137, your container has been terminated by the Linux Out-Of-Memory (OOM) killer because its resident memory exceeded the configured limits.memory.

In this triage guide, we walk through diagnosing the root cause using kubectl describe, analyzing cgroup kernel events, and tuning container memory requests and limits properly.

1. Verifying the Termination Reason

Run the following command to verify whether the pod died from an OS OOM event:

kubectl describe pod <pod-name> -n <namespace>

Look for the Last State block in the output:

Last State:     Terminated
  Reason:       OOMKilled
  Exit Code:    137
  Started:      Sat, 24 Oct 2026 14:10:02 -0700
  Finished:     Sat, 24 Oct 2026 14:18:45 -0700

If Reason says OOMKilled, the container kernel cgroup hit the ceiling.

2. Common Culprits

1. JVM MaxRAMPercentage Misconfiguration: Java applications run inside containers without -XX:MaxRAMPercentage=75.0 often inspect the node total RAM instead of the container cgroup limit.
2. Memory Leaks in Background Workers: Unbounded Redis queue consumers or unclosed file descriptors.
3. Buffer Cache Bloat: Linux page cache accumulation during intensive disk I/O.

3. Production Fix: Recommended Resource Spec

Avoid setting limits.memory equal to requests.memory for burstable microservices. Instead, allow headroom while monitoring p99 memory usage:

resources:
  requests:
    cpu: "250m"
    memory: "512Mi"
  limits:
    cpu: "1000m"
    memory: "1Gi"

Next, check our guide on tuning Prometheus alerts for Kubernetes memory saturation.