Kubernetes / Pods, Containers & Application Health
Use a container termination message as focused failure evidence
A short termination message can preserve useful startup-failure context when full logs are missing. Inspect it alongside the exit status.
Environment and inputs: Kubernetes · kubectl with supported client/server versions and delegated RBAC. Examples use namespace app unless noted. Check context, namespace, APIs and provider support first.
Start with this check
Confirm the environment and replace sample objects, namespaces, images, paths and hosts with approved targets. Share only relevant, sanitized output. Follow the workload owner’s process for changes.
kubectl -n app get pod web-0 -o jsonpath='{.status.containerStatuses[*].lastState.terminated.message}'Read the result
The output contains recorded messages where the runtime and application provided them. It may be empty, truncated or refer to a previous restart.
Resolve and verify
Match the message with the correct container and time, then investigate its specific configuration or application failure. Preserve first-cause context in the support record.
Before changing production
Do not assume a missing termination message means the container stopped normally or write secrets into termination files.