Introduction

Exit code 137 means the main process inside the container was killed with SIGKILL, which is signal 9, shown as 128 + 9 = 137. In Kubernetes, the most common cause is an out-of-memory kill, but it can also happen when the kubelet or an administrator forcefully terminates the container.

The Most Common Meaning: OOMKilled

When a container exceeds its memory limit, the kernel can terminate it immediately. Kubernetes then reports the terminated state with exit code 137 and often a reason such as OOMKilled.

That is why the first diagnostic step is always:

kubectl describe pod POD_NAME

Look for:

• 'Last State: Terminated'
• 'Reason: OOMKilled'
• memory-related events or restart history

If you see OOMKilled, the exit code is telling you the process hit a hard memory limit.

Inspect The Container Limits

A pod spec with tight limits is a common cause.

1resources:
2  requests:
3    memory: "256Mi"
4    cpu: "250m"
5  limits:
6    memory: "512Mi"
7    cpu: "500m"

If the workload occasionally needs more than 512Mi, the kernel kill is expected. Kubernetes does not gracefully negotiate beyond the limit. The process is terminated.

Check Current Usage

If metrics are available, compare real usage against limits.

kubectl top pod POD_NAME

That tells you whether the container is running close to its ceiling. Combine that with application logs to see what the workload was doing just before the kill.

Exit 137 Is Not Always OOM

Although memory is the usual cause, 137 only means SIGKILL. Other possibilities include:

• the pod was forcefully terminated after the grace period expired
• a node-level process killed the container
• an operator or automation issued a hard kill

That is why kubectl describe pod matters more than the raw exit code alone. The surrounding reason field and events give the actual context.

Common Fixes For OOMKills

If the pod is genuinely running out of memory, the usual responses are:

• increase the memory limit
• reduce in-process memory usage
• lower batch sizes or request sizes
• split work into smaller jobs
• add horizontal scaling if memory spikes come from traffic

For example, a machine-learning inference container often stops crashing after reducing batch size or model concurrency instead of only increasing limits.

Example Diagnostic Flow

A practical sequence is:

1kubectl get pod POD_NAME -o wide
2kubectl describe pod POD_NAME
3kubectl logs POD_NAME --previous
4kubectl top pod POD_NAME

This gives you:

• pod status and restart count
• termination reason and events
• the logs from the last crashed container
• recent resource usage

With those four views, most exit-137 cases become straightforward to classify.

Common Pitfalls

The most common mistake is assuming exit 137 always means memory exhaustion. It often does, but the real source is still SIGKILL, so confirm the reason before changing limits.

Another mistake is increasing only the limit without checking the request. A pod with unrealistic requests can still cause scheduling problems or noisy-neighbor behavior on the node.

A third issue is looking only at current logs after a restart. Use --previous to inspect the logs from the crashed container instance.

Summary

• Exit code 137 means the container process was killed with SIGKILL.
• In Kubernetes, the most common cause is OOMKilled due to memory limits.
• Use kubectl describe pod to confirm the reason instead of trusting the exit code alone.
• Check both resource limits and actual runtime usage.
• Fixes usually involve either more memory or less per-request memory pressure.