What does exit code 137 actually mean?
Paste any Docker or Kubernetes exit code, signal, or Pod status. Get the plain-English answer and the exact command to confirm it. No article to read.
How Exit Code Lookup works
Type your query
Enter a number (137, 143, 1, 0), a Unix signal name (SIGKILL, SIGTERM, SIGSEGV), or a Kubernetes Pod status string (CrashLoopBackOff, OOMKilled, ImagePullBackOff, Pending, Evicted).
See the instant result
The tool matches your input against a comprehensive lookup table and displays the plain-English meaning, the signal math breakdown if applicable (128 + 9 = 137), and the context for both Docker and Kubernetes environments.
Read the ranked causes
Each result lists the 2 to 5 most common causes, ranked by how frequently they appear in production. The most likely culprit is always listed first, so you can start diagnosing in the right order.
Copy the diagnostic command
Every result includes the exact kubectl or docker command to confirm the diagnosis. Click the Copy button on any command to paste it directly into your terminal.
Browse the full reference
Click 'Browse all codes and statuses' to see every exit code and every Kubernetes Pod status in a scannable table. Useful when you want to review all codes rather than look up a single one.
What the exit codes mean
Exit codes 0 through 125 are defined by the application itself. Codes above 128 follow the Unix convention of 128 + signal number, indicating the process was killed by an external signal. Here are the ones you will encounter most often.
Application-defined codes (0 to 125)
012126127Signal-based codes (128 + signal number)
130SIGINT (2)134SIGABRT (6)137SIGKILL (9)139SIGSEGV (11)143SIGTERM (15)Kubernetes Pod statuses explained
Pod statuses are what you see in the STATUS column of kubectl get pods output. They are not exit codes, but they often contain or point to the underlying exit code. Here is what each status means and what to check first.
CrashLoopBackOff
Container keeps crashing. Kubernetes is waiting longer between each restart (10s, 20s, 40s, up to 5 min). Check: kubectl logs <pod> --previous for the crash reason, then the exit code in kubectl describe.
OOMKilled
Container exceeded its memory limit. The kernel killed it immediately (exit code 137). Fix: raise the memory limit, or find and fix the memory leak.
ImagePullBackOff
Cannot pull the container image. Check: image name/tag typo, missing imagePullSecret for private registries, Docker Hub rate limiting, or network issues.
Pending
Pod accepted but not yet running. Check: insufficient node resources, unsatisfiable scheduling constraints (nodeSelector, taints), or unbound PVC.
Evicted
Pod removed from the node due to resource pressure (disk, memory, or PID exhaustion). BestEffort QoS pods are evicted first.
CreateContainerConfigError
Cannot create the container because a referenced ConfigMap or Secret does not exist. Check kubectl describe for the exact missing resource.
Unix signal reference for containers
When a container process is killed by a signal, the exit code follows the formula 128 + signal_number. Here is the complete reference for signals you will see in container environments.
| Signal | Number | Exit Code | Catchable? | Container Context |
|---|---|---|---|---|
| SIGHUP | 1 | 129 | Yes | Terminal hangup, rarely seen in containers |
| SIGINT | 2 | 130 | Yes | Ctrl+C interrupt |
| SIGQUIT | 3 | 131 | Yes | Quit with core dump |
| SIGABRT | 6 | 134 | Yes | Abort, assertion failure |
| SIGKILL | 9 | 137 | No | OOMKilled, force-kill after grace period |
| SIGSEGV | 11 | 139 | Yes | Segmentation fault |
| SIGTERM | 15 | 143 | Yes | Graceful shutdown (rolling updates, pod deletion) |
When to use this tool
| Scenario | What to type | What you get |
|---|---|---|
| Pod keeps restarting, kubectl shows exit code 137 | 137 | OOMKilled explanation + kubectl commands to check memory usage and limits |
| Rolling update shows exit code 143 in events | 143 | Confirmation this is normal SIGTERM during graceful shutdown |
| kubectl get pods shows CrashLoopBackOff | CrashLoopBackOff | The 5 most common causes and the exact diagnostic sequence |
| Container won't start, shows ImagePullBackOff | ImagePullBackOff | Registry auth, typo, rate limiting checks with commands |
| Reviewing exit codes before a Kubernetes interview | Browse all | Complete reference table of every code and status |
| Docker container exits with code 127 | 127 | Command not found: missing binary in the container image |
Frequently Asked Questions
What does the Exit Code Lookup tool do?
It instantly decodes Docker and Kubernetes container exit codes (like 137, 143, 1, 127), Unix signal names (SIGKILL, SIGTERM), and Kubernetes Pod statuses (CrashLoopBackOff, OOMKilled, ImagePullBackOff) into plain-English explanations. Each result includes the most common causes ranked by frequency and the exact kubectl or docker commands to confirm the diagnosis.
Nothing is saved, nothing is sent anywhere. The tool runs entirely in your browser using a static lookup table.
What is the difference between exit code 137 and 143?
Both follow the convention 128 + signal number, but the signals are very different.
| Exit Code 137 (SIGKILL) | Exit Code 143 (SIGTERM) | |
|---|---|---|
| Signal | SIGKILL (signal 9) | SIGTERM (signal 15) |
| Can be caught? | No, immediate kill | Yes, allows graceful shutdown |
| Common cause | OOMKilled or force-kill after grace period | Normal rolling update or pod deletion |
| Action needed? | Usually yes: raise memory limit or fix leak | Usually no: this is expected during deploys |
If you see exit code 137, run kubectl describe pod <name> and check whether the Reason field says OOMKilled. If it does, the container exceeded its memory limit.
How do I find the exit code of a crashed Kubernetes Pod?
Use kubectl describe pod to see the exit code, reason, and signal in the Last State section:
kubectl describe pod <pod-name> | grep -A 5 "Last State"
# Output example:
# Last State: Terminated
# Reason: OOMKilled
# Exit Code: 137For containers that have already restarted, the Last State section shows the previous exit. The current State section shows the current (likely Running or Waiting) status.
Why do exit codes above 128 follow the '128 + signal number' pattern?
When a process is terminated by a Unix signal rather than exiting on its own, the shell and container runtime report the exit code as 128 plus the signal number. This convention comes from POSIX shell behavior and lets you identify which signal killed the process just from the exit code.
For example: SIGKILL is signal 9, so the exit code is 128 + 9 = 137. SIGTERM is signal 15, so the exit code is 128 + 15 = 143. SIGSEGV is signal 11, so the exit code is 128 + 11 = 139.
Are Docker and Kubernetes exit codes the same?
The raw exit codes (0, 1, 137, 143, etc.) mean the same thing in both Docker and Kubernetes because they come from the underlying Linux process and container runtime. The difference is in how each platform surfaces them and what additional context they provide.
Docker shows exit codes via docker inspect and has its own restart policies (no, on-failure, always, unless-stopped). Kubernetes wraps the same exit codes in a richer status system with Pod statuses (CrashLoopBackOff, OOMKilled), probe-driven restarts, and detailed events visible through kubectl describe.
Why isn't CrashLoopBackOff an exit code?
CrashLoopBackOff is a Kubernetes Pod status, not an exit code. It means the container keeps crashing and restarting, and Kubernetes is applying an exponential backoff delay (10s, 20s, 40s, up to 5 minutes) between restart attempts.
The actual root cause is indicated by the exit code of the crashed container (often exit code 1 for application errors, or 137 for OOMKilled). CrashLoopBackOff is the symptom; the exit code tells you why the crash happened. Check both with kubectl describe pod.