How to fix Exit Code 137 in Kubernetes

KubernetesINTERMEDIATEHIGHUpdated Dec 6, 2025· 248 views

Exit code 137 indicates your container was killed by SIGKILL (signal 9), typically due to OOMKilled when exceeding memory limits. Increase memory limits or optimize application memory usage.

Quick fix

Fixes Exit Code 137

kubectl describe pod <pod-name>
  1. Confirm the termination reason
  2. Check current memory configuration and usage
  3. Increase memory limits
  4. Check for memory leaks
kubernetes — error
kubectl describe pod <pod-name>
Exit Code 137

What this error means

Exit code 137 in Kubernetes means a container was forcibly terminated by the Linux kernel using SIGKILL (signal 9). The number 137 is calculated as 128 (base code for fatal signals) + 9 (SIGKILL signal number). The most common cause is OOMKilled—the kernel's out-of-memory killer terminated the container because it exceeded its memory limit. However, SIGKILL can also come from manual kills, failed health checks triggering termination, or node-level memory pressure causing pod eviction.

Typical symptoms

  • Container shows OOMKilled status in kubectl describe pod output
  • Pod repeatedly crashes and enters CrashLoopBackOff state
  • Exit Code: 137 appears in Last State of container status
  • Container terminates abruptly without graceful shutdown logs
  • Memory usage steadily increases before sudden termination
  • Application works initially but crashes under load
  • Events show Killing container with grace period or OOM events

Common causes

  1. Container memory usage exceeds the configured memory limit
  2. Memory leak in application causing gradual consumption growth
  3. Memory limits set too low for actual workload requirements
  4. JVM or runtime heap configured larger than container limit allows
  5. Traffic spike causing memory usage to exceed normal levels
  6. Node memory pressure triggering pod eviction
  7. Liveness probe failures causing Kubernetes to kill the container
  8. Manual termination via kubectl delete with force flag

How to fix "Exit Code 137"

1Confirm the termination reason

Check if the container was OOMKilled:

bash
kubectl describe pod <pod-name>

Look for these indicators in the output:

bash
Last State:     Terminated
  Reason:       OOMKilled
  Exit Code:    137

If Reason shows OOMKilled, it's a memory issue. If it shows Error, check for other causes like liveness probe failures.

2Check current memory configuration and usage

View the pod's memory limits:

bash
kubectl get pod <pod-name> -o jsonpath='{.spec.containers[*].resources}'

Monitor actual memory consumption:

bash
kubectl top pod <pod-name>

Compare actual usage to limits. If usage approaches limits before crashes, the limits are too low.

3Increase memory limits

Update your deployment with appropriate memory limits:

yaml
resources:
  requests:
    memory: "512Mi"
  limits:
    memory: "1Gi"

Set requests based on typical usage and limits for peak load. Start with limits at 1.5-2x your observed normal usage. Apply and monitor:

bash
kubectl apply -f deployment.yaml
kubectl top pod <pod-name> --watch
4Check for memory leaks

If memory grows continuously until OOM, investigate leaks:

bash
# Watch memory over time
kubectl top pod <pod-name> --watch

For Java applications, enable heap dumps:

yaml
env:
  - name: JAVA_OPTS
    value: "-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/heapdump.hprof"

Use language-specific profilers (pprof for Go, memory_profiler for Python) to identify leak sources.

5Review liveness probe configuration

Aggressive liveness probes can also cause exit code 137 if they kill the container:

bash
kubectl describe pod <pod-name> | grep -A 10 "Liveness"

If probes are too aggressive, adjust timeouts:

yaml
livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 60
  periodSeconds: 30
  timeoutSeconds: 10
  failureThreshold: 3
6Use Guaranteed QoS for critical workloads

Pods with Guaranteed QoS are killed last during node memory pressure:

yaml
resources:
  requests:
    memory: "1Gi"
    cpu: "500m"
  limits:
    memory: "1Gi"
    cpu: "500m"

When requests equal limits, the pod gets Guaranteed QoS class. BestEffort pods (no limits) are killed first.

Advanced notes

Exit code 137 differs from exit code 143 (SIGTERM). Code 137 is SIGKILL—immediate, ungraceful termination that cannot be caught or handled by the application. Code 143 is SIGTERM—a graceful shutdown request.

On EKS, use CloudWatch Container Insights to track memory trends over time. On GKE, Cloud Monitoring provides memory metrics, though console graphs may differ from kubectl top. On AKS, Azure Monitor can correlate OOM events with other cluster metrics.

Consider Vertical Pod Autoscaler (VPA) to automatically adjust memory limits based on historical usage. For predictable memory growth patterns, combine with Horizontal Pod Autoscaler (HPA) to scale out before individual pods hit their limits.

Node-level OOM can kill pods even within their limits if the node is overcommitted. Monitor node memory with kubectl describe node and look for MemoryPressure conditions.

Frequently asked questions

What does "Exit Code 137" mean?
Exit code 137 in Kubernetes means a container was forcibly terminated by the Linux kernel using SIGKILL (signal 9). The number 137 is calculated as 128 (base code for fatal signals) + 9 (SIGKILL signal number). The most common cause is OOMKilled—the kernel's out-of-memory killer terminated the container because it exceeded its memory limit.
How do I fix "Exit Code 137"?
Exit code 137 indicates your container was killed by SIGKILL (signal 9), typically due to OOMKilled when exceeding memory limits. Increase memory limits or optimize application memory usage.
What causes "Exit Code 137"?
Container memory usage exceeds the configured memory limit Memory leak in application causing gradual consumption growth Memory limits set too low for actual workload requirements
Is the "Exit Code 137" error serious?
Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading