How to fix Exit Code 143 (SIGTERM) in Kubernetes

KubernetesBEGINNERLOWUpdated May 28, 2026· 249 views

Exit code 143 means the container was stopped by SIGTERM during shutdown. Fix premature kills by adding a SIGTERM handler and raising terminationGracePeriodSeconds.

Quick fix

Fixes Exit Code 143 (SIGTERM)

# Check recent events
kubectl get events --sort-by='.lastTimestamp' | grep <pod-name>

# See what triggered termination
kubectl describe pod <pod-name>
  1. Verify this is expected behavior
  2. Implement SIGTERM handling in your application
  3. Adjust termination grace period if needed
  4. Use preStop hooks for additional cleanup
kubernetes — error
# Check recent events
kubectl get events --sort-by='.lastTimestamp' | grep <pod-name>
# See what triggered termination
kubectl describe pod <pod-name>
Exit Code 143 (SIGTERM)

What this error means

Exit code 143 indicates that a container was terminated by a SIGTERM signal (signal 15). The exit code is calculated as 128 + 15 = 143. SIGTERM is the standard signal for requesting graceful termination. Unlike exit code 137 (SIGKILL), code 143 is not an error—it's the expected result of proper graceful shutdown. Kubernetes sends SIGTERM when scaling down, during rolling updates, or when explicitly deleting pods. The container has a grace period (default 30 seconds) to clean up before receiving SIGKILL.

Typical symptoms

  • Container exits with code 143 during deployments or scaling
  • Pod terminates cleanly during rolling updates
  • Exit code 143 after kubectl delete pod command
  • Container shows Terminated status after node drain
  • Logs show graceful shutdown messages before termination
  • Application completes cleanup within grace period

Common causes

  1. Deployment scaled down or updated with rolling strategy
  2. Pod explicitly deleted by user or controller
  3. Node drained for maintenance or cluster scaling
  4. Resource quota exceeded causing pod eviction
  5. Liveness probe failures triggering pod replacement
  6. HorizontalPodAutoscaler reducing replica count
  7. Cluster autoscaler removing underutilized nodes

How to fix "Exit Code 143 (SIGTERM)"

1Verify this is expected behavior

Exit code 143 is normal during these operations:

bash
# Check recent events
kubectl get events --sort-by='.lastTimestamp' | grep <pod-name>

# See what triggered termination
kubectl describe pod <pod-name>

If the pod was terminated during a deployment, scale operation, or node maintenance, exit code 143 is expected and correct.

2Implement SIGTERM handling in your application

Ensure your application handles SIGTERM for graceful shutdown:

Python:

python
import signal

def shutdown_handler(signum, frame):
    print("SIGTERM received, shutting down gracefully...")
    # Close database connections
    # Finish processing current requests
    # Flush logs and metrics
    sys.exit(0)

signal.signal(signal.SIGTERM, shutdown_handler)

Node.js:

javascript
process.on('SIGTERM', async () => {
  console.log('SIGTERM received, starting graceful shutdown');
  await server.close();
  await db.disconnect();
  process.exit(0);
});
3Adjust termination grace period if needed

If your application needs more time to shut down gracefully:

yaml
spec:
  terminationGracePeriodSeconds: 60  # Default is 30
  containers:
  - name: app
    image: myapp:latest

During this period:
1. SIGTERM is sent to the container
2. Application has time to complete cleanup
3. If not terminated, SIGKILL is sent after grace period

4Use preStop hooks for additional cleanup

Add a preStop lifecycle hook for cleanup without code changes:

yaml
lifecycle:
  preStop:
    exec:
      command: ["/bin/sh", "-c", "sleep 10 && /app/cleanup.sh"]

The preStop hook runs before SIGTERM is sent, giving additional time for:
- Draining connections from load balancers
- Completing in-flight requests
- Deregistering from service discovery

5Distinguish from problematic terminations

Exit code 143 is healthy; watch for these patterns instead:

Concerning:
- Exit code 137 (SIGKILL) - forced kill, possibly OOM
- Frequent terminations outside of deployments
- Short-lived pods constantly receiving SIGTERM

Check if eviction is the cause:

bash
kubectl describe pod <pod-name> | grep -A 5 "Status:"
kubectl top pod <pod-name>  # Check resource usage

Eviction due to resource pressure may indicate undersized limits.

6Monitor graceful shutdown completion

Verify your application actually completes graceful shutdown:

bash
# Watch logs during termination
kubectl logs -f <pod-name>

# Delete and observe shutdown
kubectl delete pod <pod-name>

Look for your shutdown messages in logs. If the pod terminates with 143 but logs show incomplete cleanup, your grace period may be too short or shutdown logic has issues.

Advanced notes

Exit code 143 vs 137: Both indicate signal-based termination, but they're very different:
- 143 (SIGTERM): Graceful request, application can handle it
- 137 (SIGKILL): Forced termination, application cannot catch or handle it

If you see 137 instead of 143, your application didn't exit within the grace period, or Kubernetes force-killed it due to OOM.

For zero-downtime deployments, combine proper SIGTERM handling with:
- Readiness probes that fail during shutdown
- preStop hooks that wait for connection draining
- PodDisruptionBudgets to limit simultaneous terminations

In service meshes like Istio, the sidecar also needs to handle termination. Istio 1.12+ supports native sidecar termination ordering to ensure the app shuts down before the proxy.

Frequently asked questions

What does "Exit Code 143 (SIGTERM)" mean?
Exit code 143 indicates that a container was terminated by a SIGTERM signal (signal 15). The exit code is calculated as 128 + 15 = 143. SIGTERM is the standard signal for requesting graceful termination.
How do I fix "Exit Code 143 (SIGTERM)"?
Exit code 143 means the container was stopped by SIGTERM during shutdown. Fix premature kills by adding a SIGTERM handler and raising terminationGracePeriodSeconds.
What causes "Exit Code 143 (SIGTERM)"?
Deployment scaled down or updated with rolling strategy Pod explicitly deleted by user or controller Node drained for maintenance or cluster scaling
Is the "Exit Code 143 (SIGTERM)" error serious?
It is a low-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading