Container exited unexpectedly

What this failure means

The container started but then exited with a non-zero status code. If it keeps restarting, Kubernetes enters CrashLoopBackOff and the pod never becomes ready.

Symptoms

Faultline looks for one or more of these log fragments:

container exited with
exit code 1
exit code 139
container is restarting

Diagnosis

The container started but then exited with a non-zero status code. If it keeps restarting, Kubernetes enters CrashLoopBackOff and the pod never becomes ready.

CrashLoopBackOff is the platform symptom. The root cause is usually in the last container logs, the exit code, or the startup configuration passed to the image.

Fix steps

1. Retrieve the logs from the previous crashed container: kubectl logs <pod> --previous.
2. Check the exit code with kubectl describe pod <pod> — look for the Last State block.
3. If exit 137, increase the memory limit in the container spec or profile memory usage.
4. If exit 139, inspect the logs for segfaults or crashes in native extensions.
5. If exit 1, search the log output for FATAL, panic, or unhandled exception traces.
6. Reproduce the failure locally with docker run using the same image and environment variables.

Validation

• Re-run the failing workflow step.
• Confirm the original failure signature for Container exited unexpectedly is gone.

Why it matters

Non-zero exit codes indicate an unhandled error at runtime. Exit 137 is SIGKILL (often an OOM kill or a forced stop). Exit 139 is a segfault. Exit 1 is a generic application error. CrashLoopBackOff is the symptom; the root cause is always in the container logs.

Prevention

• Set explicit memory and CPU limits to surface resource problems early.
• Validate required configuration at startup and exit early with a clear message if anything is missing.
• Run the container image in CI with a smoke test before merging.

Try it locally

kubectl logs <pod> --previous
kubectl describe pod <pod>
kubectl rollout status deploy/<name>
kubectl get pods

How Faultline detects it

Use faultline explain container-crash to see the full playbook.

faultline analyze build.log
faultline explain container-crash

Generated from playbooks/bundled/log/deploy/container-crash.yaml. Do not edit directly.