Exit code 143: The process was terminated by SIGTERM

Exit code 143 means the process received SIGTERM and exited. During a rolling update, scale-down, or node drain this is normal shutdown behaviour and not a fault.

Applies to: All Kubernetes versions, Linux nodes

What it means

143 is 128 + 15, and signal 15 is SIGTERM — the polite request to stop. Kubernetes sends SIGTERM to a container's main process when the pod is being terminated, then waits up to terminationGracePeriodSeconds before sending SIGKILL. A container that exits with 143 therefore did what it was asked. The reason this code causes confusion is that it shows up in dashboards and alerting alongside genuine failures, and a rolling deployment generates a burst of them. Treat 143 as a fault only when the pod was not supposed to be terminating.

Most common causes

• A normal rolling update replacing the pod.
• A scale-down, manual delete, or node drain.
• Eviction by the node under resource pressure, or preemption by a higher-priority pod.
• A liveness probe failure causing the kubelet to restart the container.
• The horizontal pod autoscaler reducing replica count.

How to diagnose it

1. Check whether a deployment, scale event, or drain was in progress at that moment — kubectl get events --sort-by=.lastTimestamp.
2. If the termination was unexpected, look for Liveness probe failed in kubectl describe pod POD, which indicates the kubelet decided the container was unhealthy.
3. Check for eviction or preemption messages in the pod's events if the node was under pressure.

How to fix it

1. If the shutdown was intended, nothing needs fixing — filter 143 out of failure alerting during rollouts so it does not mask real problems.
2. If a liveness probe caused it, correct the probe rather than the application: check the path, port, timeout, and failure threshold, and add a startupProbe for slow starters.
3. If pods are being evicted or preempted, address node capacity, resource requests, or pod priority.

Notes

If your application is receiving SIGTERM but not shutting down cleanly, connections can be dropped mid-request during every deploy. Handling SIGTERM by draining connections before exiting is what makes rollouts invisible to users.

Related

• Exit code 137 — Process killed by SIGKILL

Sources

• Kubernetes documentation — Pod Lifecycle: termination of pods
• Kubernetes documentation — Configure Liveness, Readiness and Startup Probes