OneLinersCommand workbench
Verified diagnostic signature

Kubernetes failed to start container: locate the runtime failure before expecting app logs

A Kubernetes-qualified start event reports that the runtime could not start the container. Preserve the concrete inner reason and stage before assuming an application crash, registry password problem or liveness timeout. The process may not have started, so its application log may be absent. The reviewed kubelet source records a runtime StartContainer failure separately from successful start and subsequent lifecycle-hook handling; not every similarly worded error is a Kubernetes event. Match this output from kubernetes, then continue with sourced, read-only checks.

Confidence
high
Platforms
linux · macos · windows
Verified
2026-10-01
Recognized output

Signature matched locally

Kubernetes failed to start container: locate the runtime failure before expecting app logs

OneLiners matches this pattern in your browser. Your pasted output is not stored or indexed.

Likely causes

What usually produces this signal

  1. The runtime cannot execute the effective entry point or its interpreter because the approved image/path/platform does not match what was deployed. Retain the precise missing-file, format or permission reason from the responsible runtime owner. A bare failed-to-start wrapper does not identify which file or architecture is wrong; an image's existence in a registry does not prove its executable can run on this node.
  2. An admitted security or runtime boundary rejects startup. Effective user, execution policy, mount restrictions or runtime configuration require stage-specific sanitized evidence, not a guessed chmod fix. Do not turn the workload privileged, disable security profiles or make a filesystem world-writable merely to see whether the error disappears. A permission grant can hide the symptom while weakening isolation.
  3. Another lifecycle stage has been mislabeled as a process-start failure. Separate image acquisition, container creation, runtime StartContainer and a failed PostStart hook; a hook can fail after process startup. Correlate the event with UID/container and the original node/runtime version. A desktop Docker message or a source label on an earlier line cannot authorize Kubernetes-specific recovery.
Safe next checks

Collect evidence before changing the system

01

Locate the affected waiting/termination stage for the exact admitted container

# Replace approved-context, approved-namespace and pod-name with owner-approved identities.
# Read-only, named Pod only; keep private names/results local and do not broaden RBAC.
kubectl --context "approved-context" --namespace "approved-namespace" get pod "pod-name" --request-timeout=10s -o=jsonpath="{.metadata.uid}{'\n'}{.spec.nodeName}{'\n'}{.status.phase}{'\n'}{range .status.initContainerStatuses[*]}{.name}{'\t'}{.ready}{'\t'}{.restartCount}{'\t'}{.state.waiting.reason}{'\t'}{.state.terminated.reason}{'\t'}{.state.terminated.exitCode}{'\t'}{.lastState.terminated.reason}{'\t'}{.lastState.terminated.exitCode}{'\t'}{.lastState.terminated.finishedAt}{'\n'}{end}{range .status.containerStatuses[*]}{.name}{'\t'}{.ready}{'\t'}{.restartCount}{'\t'}{.state.waiting.reason}{'\t'}{.state.terminated.reason}{'\t'}{.state.terminated.exitCode}{'\t'}{.lastState.terminated.reason}{'\t'}{.lastState.terminated.exitCode}{'\t'}{.lastState.terminated.finishedAt}{'\n'}{end}"

Expected signal: The Pod projection separates init/application status, waiting reason and prior termination. Retain the UID, node and container name to associate the original start event. Missing process state or logs leave startup uncertain, not successful. Do not borrow lastState from another container to claim this attempt executed.

A reported RunContainerError-style reason is not a complete root cause and varies with runtime/version. The projection deliberately omits raw messages, command arguments and environment. Ask the deployment owner to compare the effective image/entry point locally without exporting secrets or running a new debug container.

02

Identify the responsible runtime's original failure stage and safe inner reason

# Owner-local review only: correlate this Pod UID/container/node with its bounded start event.
# Separate image acquisition, create, StartContainer and PostStart hook records.
# Compare the approved executable/interpreter/platform and effective security policy with the precise reason.
# No kubectl exec/debug/run, node SSH, image execution, chmod or privilege/security changes.

Expected signal: The responsible owner identifies whether process startup was attempted and retains a concrete sanitized missing executable, format, permission or runtime reason. If that evidence is unavailable, the diagnosis remains unresolved. A failure after a successful start/hook stage is analyzed separately rather than asserted to have no application process.

The application cannot safely test a production node's runtime by launching arbitrary images. Use existing approved incident evidence and preserve its version/stage. Absence of application logs is compatible with failure before execution, but is not proof: logs can also be unavailable or expired. Any image or security remediation remains an owner-controlled release operation.

Reproducible example

Check the input against the result

Input and result

Warning Failed 10s kubelet Error: failed to start container api
# Source-shaped event; no container process was executed.
# Executed bounded owned HTTP/JSON controls, NOT a Kubernetes cluster:
owned_start_record: stage=StartContainer application_started=false process_logs_available=false
constructed_inner_reason: exec: /app/missing: no such file or directory
separate_hook_record: stage=PostStart application_started=true
owned_waiting: reason=RunContainerError
CRI_start_binary_lookup_hook_or_permissions=not_executed

Actual owned HTTP/JSON reads compared an explicitly constructed failed-start record with a different post-start hook record. The fixture supplied process/log availability and inner reason; no executable lookup, permission check, OCI runtime or Kubernetes hook actually ran. It proves only that these supplied stages must not be conflated, not why a real production container failed or that it recovered.

Evidence-led recovery

Correct only the demonstrated cause

The image, application or runtime owner corrects the evidenced executable/platform/configuration/security mismatch through a reviewed release or approved node-management change. Preserve the original error stage and rollback. Do not execute the image casually, change every workload's entry point, disable confinement or add privilege as an exploratory fix.

Verify: The normal affected runtime starts the intended approved container and completes its lifecycle/startup/readiness checks without the original stage failure. Check the actual UID/revision/node identity and application behavior, including hooks. A successful image pull or an administrator's unrelated Docker run is not equivalent verification.

Stop if: The event source/stage, approved image or assigned runtime is unknown; evidence belongs to another attempt; or the proposed fix requires node access, unreviewed execution, world-writable permissions, disabled security or private command/env disclosure.

Related signals

Other output patterns from this error family

Kubernetes CrashLoopBackOff: diagnose the last termination before changing retriesCrashLoopBackOff describes a container waiting between repeated restart attempts. It is not a Pod phase, a diagnosis of application code, or proof of exhausted memory. Establish the exact Pod UID and init/application container, then inspect the most recent termination and the relevant policy. A Pod can have phase Running while this container is waiting and not ready. Do not treat a displayed retry count or age as the precise next restart time.Kubernetes Back-off restarting failed container: correlate the event with current stateThis BackOff event reports a delayed container restart, not the error that originally stopped execution. Its repeated occurrence count is not a count of newly created containers, and an old event can remain visible after the current instance starts. Bind the event's involvedObject UID to the actual Pod and affected container before interpreting a restart rate or root cause. BackOff for restarting a container is a different operation from an image-pull retry.Kubernetes OOMKilled: separate the termination reason from exit code and current metricsOOMKilled is a reported container termination reason associated with an out-of-memory kill. It does not identify the exact allocation, prove a leak, or tell you whether container-level limits or wider node pressure were responsible. Preserve which state or lastState recorded it and when. Exit code 137 without OOMKilled is not the same evidence, and a low metric from a later restarted container cannot disprove the earlier memory incident.Kubernetes liveness probe failed: separate health-check failure from readiness and restartThe kubelet's liveness check returned a failure for a container. One failed event is not proof that a restart already happened, that a browser cannot reach the Service, or that the application needs more memory. Correlate the affected container's admitted probe, failure tolerance and recent termination/status. Liveness, readiness and startup checks have different roles; a readiness failure must not be treated as a container restart instruction.