How This Exit Code Reference Works
This exit code reference covers 33 codes you can search by number, signal name, or keyword. Type a code number, a signal name, or a keyword from a description into the search box and this bash exit codes list narrows down instantly. Results are grouped into three categories: standard Bash conventions (0 for success, 1 for a general application error, 2 for shell builtin misuse, 126/127 for permission or PATH problems), fatal signal codes (128 plus the signal number, covering crashes and forced kills), and BSD sysexits.h conventions (64 through 78, a set of specific exit code meanings some Unix utilities follow for clearer error classification).
Signal Exit Codes: The 128+N Pattern
When a process is terminated by a signal rather than exiting normally, the shell reports an exit code of 128 plus the signal number, this is the pattern behind every code in the 129-165 range that looks unusually high for a simple error. A signal exit code calculator reading works the same in reverse, subtract 128 from the code to get the signal number: an exit code 137 meaning of SIGKILL (128 + 9), or an exit code 139 meaning of SIGSEGV (128 + 11). This convention is why codes like 130 and 137 show up constantly in CI logs and container orchestration, they're not arbitrary, they map directly to a specific signal.
| Code | Signal | What it typically means |
|---|---|---|
| 130 | SIGINT (128+2) | Interrupted with Ctrl+C |
| 137 | SIGKILL (128+9) | Force-killed, often the OOM killer |
| 139 | SIGSEGV (128+11) | Segmentation fault, invalid memory access |
| 143 | SIGTERM (128+15) | Graceful shutdown request from kill or an orchestrator |
Exit Code 137 and Docker/Kubernetes OOM Kills
Exit code 137 meaning in a container context deserves its own callout since it's one of the most frequently searched exit codes: a container exiting with 137 was almost always killed by SIGKILL, and in Docker or Kubernetes specifically, the overwhelmingly common cause is the OOM (out-of-memory) killer terminating the container's main process because it exceeded its memory limit. The docker exit code meaning here isn't a bug in the application necessarily, it's the kernel or container runtime enforcing a memory ceiling, the fix is usually raising the memory limit or finding and fixing a memory leak, not debugging application logic for a thrown exception.
Common Uses
Decoding a failing CI job's exit code to figure out whether it was an application error or a killed process, diagnosing why a Docker container exited with 137 or 143, distinguishing what does exit code 1 mean (a generic application-level failure) from exit code 2 (shell builtin misuse) from a 128+N signal code (a crash or forced kill), and checking sysexits.h reference codes in scripts or utilities that follow that older BSD convention are the most common uses of this shell script exit code list. Quickly confirming a code's category before digging into logs is a common secondary use, since it narrows the search from a vague failure to a specific, known failure class.
What This Tool Doesn't Do
This is a curated linux exit codes explained reference covering 33 well-documented codes, not exhaustive coverage of every value from 0 to 255, most codes outside the ones listed here (many values between 3 and 125, and most of 79 through 127 excluding the documented ones) are application-specific and have no standard meaning at all, they mean whatever the specific program that returned them intends. This tool also doesn't inspect a real running process or an actual command's exit status, it's a static lookup, not a live diagnostic, run echo $? after a command yourself to see the actual code, then look it up here.