Komodor is an autonomous AI SRE platform for Kubernetes. Powered by Klaudia, it’s an agentic AI solution for visualizing, troubleshooting and optimizing cloud-native infrastructure, allowing enterprises to operate Kubernetes at scale.
Proactively detect & remediate issues in your clusters & workloads.
Easily operate & manage K8s clusters at scale.
Reduce costs without compromising on performance.
Guides, blogs, webinars & tools to help you troubleshoot and scale Kubernetes.
Tips, trends, and lessons from the field.
Practical guides for real-world K8s ops.
How it works, how to run it, and how not to break it.
Short, clear articles on Kubernetes concepts, best practices, and troubleshooting.
Infra stories from teams like yours, brief, honest, and right to the point.
Product-focused clips showing Komodor in action, from drift detection to add‑on support.
Live demos, real use cases, and expert Q&A, all up-to-date.
The missing UI for Helm – a simplified way of working with Helm.
Visualize Crossplane resources and speed up troubleshooting.
Validate, clean & secure your K8s YAMLs.
Navigate the community-driven K8s ecosystem map.
Who we are, and our promise for the future of K8s.
Have a question for us? Write us.
Come aboard the K8s ship – we’re hiring!
Here’s what they’re saying about Komodor in the news.
Join the Komodor partner program and accelerate growth.
More than half of all organizations running containers will experience an incident this year. Nearly one in three of those will face a data breach or network compromise as a result. Most container failures announce themselves clearly if you know what to look for. Container exit codes are your first and fastest diagnostic tool, and this guide breaks down every single one.
Exit codes are used by container engines, when a container terminates, to report why it was terminated.
If you are a Kubernetes user, container failures are one of the most common causes of pod exceptions, and understanding container exit codes can help you get to the root cause of pod failures when troubleshooting and increasingly, teams are turning to AI SRE platforms to automate that process at scale.
The most common exit codes used by containers are:
Below we’ll explain how to troubleshoot failed containers on a self-managed host and in Kubernetes, and provide more details on all of the exit codes listed above.
This is part of an extensive series of guides about Observability.
To better understand the causes of container failure, let’s discuss the lifecycle of a container first. Taking Docker as an example – at any given time, a Docker container can be in one of several states:
When a container reaches the Exited status, Docker will report an exit code in the logs, to inform you what happened to the container that caused it to shut down.
Itiel Shwartz
Co-Founder & CTO
In my experience, here are tips that can help you better handle exit codes in containers and Kubernetes:
Set appropriate resource limits to prevent OOMKilled (exit code 137) and other resource-related issues.
Implement these probes to detect and respond to container failures automatically.
Configure restart policies to handle transient issues without manual intervention.
Collect and analyze logs for all containers to quickly identify the root cause of failures.
Implement health checks in your containerized applications to detect and resolve issues proactively.
Below we cover each of the exit codes in more detail.
Exit Code 0 is triggered by developers when they purposely stop their container after a task completes. Technically, Exit Code 0 means that the foreground process is not attached to a specific container.
What to do if a container terminated with Exit Code 0?
Exit Code 1 indicates that the container was stopped due to one of the following:
What to do if a container terminated with Exit Code 1?
Exit Code 125 means that the command is used to run the container. For example docker run was invoked in the system shell but did not execute successfully. Here are common reasons this might happen:
docker run
docker run --abcd
What to do if a container terminated with Exit Code 125?
docker start
Exit Code 126 means that a command used in the container specification could not be invoked. This is often the cause of a missing dependency or an error in a continuous integration script used to run the container.
What to do if a container terminated with Exit Code 126?
Exit Code 127 means a command specified in the container specification refers to a non-existent file or directory.
What to do if a container terminated with Exit Code 127?
Same as Exit Code 126, identify the failing command and make sure you reference a valid filename and file path available within the container image.
Learn more in our detailed guide to exit code 127.
Exit Code 128 means that code within the container triggered an exit command, but did not provide a valid exit code. The Linux exit command only allows integers between 0-255, so if the process was exited with, for example, exit code 3.5, the logs will report Exit Code 128.
exit
exit code 3.5
What to do if a container terminated with Exit Code 128?
Why some exit codes map to signals: In Bash and many Unix-style tools, when a process terminates due to a fatal signal with number N, the reported exit status is often 128 + N. For example, SIGKILL is signal 9 (so 128 + 9 = 137), and SIGTERM is signal 15 (so 128 + 15 = 143). Sources: Bash Reference Manual (Exit Status), Linux signal(7).
N
128 + N
SIGKILL
128 + 9 = 137
SIGTERM
128 + 15 = 143
Exit Code 134 means that the container abnormally terminated itself, closed the process and flushed open streams. This operation is irreversible, like SIGKILL (see Exit Code 137 below). A process can trigger SIGABRT by doing one of the following:
Calling the abort() function in the libc libraryCalling the assert() macro, used for debugging. The process is then aborted if the assertion is false.
abort()
libc
assert()
What to do if a container terminated with Exit Code 134?
Exit Code 137 is one of the most time-sensitive failures you’ll encounter. If your team is dealing with frequent SIGKILL events, reducing MTTR with an AI SRE agent can significantly cut the time between detection and resolution.
Exit Code 137 means that the container has received a SIGKILL signal from the host operating system. This signal instructs a process to terminate immediately, with no grace period. This can be either:
docker kill
kill -9
docker inspect
OOMKilled
OOMKilled errors are often a symptom of under-resourced containers, which is also a cost efficiency problem. If you’re running on AWS, our complete guide to EKS cost optimization covers how to right-size workloads and prevent these failures before they happen.
Learn more in our detailed guide to exit code 137.
What to do if a container terminated with Exit Code 137?
Learn more in our detailed guide to the SIGKILL signal >>
Exit Code 139 means that the container received a SIGSEGV signal from the operating system. This indicates a segmentation error – a memory violation, caused by a container trying to access a memory location to which it does not have access. There are three common causes of SIGSEGV errors:
What to do if a container terminated with Exit Code 139?
Learn more in our detailed guide to the SIGSEGV signal >>
Exit Code 143 means that the container received a SIGTERM signal from the operating system, which asks the container to gracefully terminate, and the container succeeded in gracefully terminating (otherwise you will see Exit Code 137). This exit code can be:
docker stop
docker-compose
What to do if a container terminated with Exit Code 143?
Check host logs to see the context in which the operating system sent the SIGTERM signal. If you are using Kubernetes, check the kubelet logs to see if and when the pod was shut down.
In general, Exit Code 143 does not require troubleshooting. It means the container was properly shut down after being instructed to do so by the host.
Learn more in our detailed guide to the SIGTERM signal >>
Whenever containers fail within a pod, or Kubernetes instructs a pod to terminate for any reason, containers will shut down with exit codes. Identifying the exit code can help you understand the underlying cause of a pod exception.
You can use the following command to view pod errors: kubectl describe pod [name]
kubectl describe pod [name]
The result will look something like this:
Containers: kubedns: Container ID: ... Image: ... Image ID: ... Ports: ... Host Ports: ... Args: ... State: Running Started: Fri, 15 Oct 2021 12:06:01 +0800 Last State: Terminated Reason: Error Exit Code: 255 Started: Fri, 15 Oct 2021 11:43:42 +0800 Finished: Fri, 15 Oct 2021 12:05:17 +0800 Ready: True Restart Count: 1
Use the Exit Code provided by kubectl to troubleshoot the issue:
kubectl
exit(-1)
Refer to the relevant section above to see how to troubleshoot the container for each exit code.
As a Kubernetes administrator or user, pods or containers terminating unexpectedly can be a pain and can result in severe production issues. The troubleshooting process in Kubernetes is complex and, without the right tools, can be stressful, ineffective, and time-consuming.
Misconfigurations like insufficient permissions (Exit Code 125) or missing resource limits are also among the biggest drivers of wasted Kubernetes spend. Our complete guide to Kubernetes cost optimization shows how to address both reliability and cost in one sweep.
Some best practices can help minimize the chances of container failure affecting your applications, but eventually, something will go wrong—simply because it can.
This is the reason why we created Komodor, a tool that helps dev and ops teams stop wasting their precious time looking for needles in (hay)stacks every time things go wrong.
Acting as a single source of truth (SSOT) for all of your k8s troubleshooting needs, Komodor offers:
A container exit code is a number reported by the container engine when a container terminates, explaining why it stopped. It helps developers and Kubernetes administrators diagnose whether a container exited normally, crashed due to an application error, or was killed by the operating system via a signal like SIGKILL or SIGTERM.
Exit code 137 means the container received a SIGKILL signal and was immediately terminated with no grace period. Common causes include running out of memory (OOMKilled), a manual docker kill command, a kill -9 Linux command, or Kubernetes forcefully terminating a pod after its 30-second graceful shutdown window expired.
Exit code 1 indicates the container stopped due to an application error or an invalid reference in the image specification. This could be a programming error like dividing by zero, a runtime environment issue, or the image pointing to a file that doesn’t exist inside the container.
Exit code 0 means the container stopped intentionally and successfully. It signals that the foreground process completed its task and was not attached to a running container. No troubleshooting is typically required. Developers use this to indicate a planned, clean container shutdown.
Exit code 143 means the container received a SIGTERM signal and shut down gracefully. Exit code 137 means it received SIGKILL and was forcefully terminated immediately. If a container ignores SIGTERM and doesn’t shut down within the grace period, the OS escalates to SIGKILL, switching the exit code from 143 to 137.
Together with our content partners, we have authored in-depth guides on several other topics that can also be useful as you explore the world of observability.
Authored by Tigera
Authored by Komodor
Share:
Gain instant visibility into your clusters and resolve issues faster.
