OneLinersCommand workbench
Verified diagnostic signature

Kubernetes Back-off restarting failed container: correlate the event with current state

This 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. 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 Back-off restarting failed container: correlate the event with current state

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

Likely causes

What usually produces this signal

  1. The kubelet has seen repeated failure and is delaying another start. Preserve the last termination and its time rather than treating every BackOff message as a new application error. A memory termination, startup exception or failed liveness check may all precede the same wrapper, but each needs its own supporting evidence and a different recovery decision.
  2. The event is an aggregated or stale observation while the container status reflects a later attempt. Compare snapshots for the same UID and container; a restart count can remain unchanged while the backoff event is observed several times. Event timestamps and availability depend on retention/aggregation. Neither an empty events list nor a last-observed age proves the original fault was absent.
  3. A same-name replacement or a different init/application container has been mistaken for the original event target. Controller replacement changes Pod identity, while container restarts inside a Pod normally retain it. Separate the old incident from rollout evidence and the intended release. Do not count another replica's successful startup as verification of this actor or use image-pull BackOff evidence to diagnose a process crash.
Safe next checks

Collect evidence before changing the system

01

Select restart events by the actual Pod UID instead of the reusable name

# 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.
# Replace pod-uid with the observed UID, not a reusable Pod name.
kubectl --context "approved-context" --namespace "approved-namespace" get events --request-timeout=10s --field-selector="involvedObject.uid=pod-uid" -o=jsonpath="{range .items[*]}{.involvedObject.uid}{'\t'}{.reason}{'\t'}{.type}{'\t'}{.eventTime}{'\t'}{.lastTimestamp}{'\t'}{.series.lastObservedTime}{'\n'}{end}"

Expected signal: Only events whose involvedObject.uid equals the observed Pod UID are projected. Identify reason/type and available timestamps; privately retain the bounded sanitized restart message to distinguish it from an image-pull BackOff. Missing fields or no retained events leave the earlier cause unresolved, not disproved.

The core Event UID field selector is intentional; do not expand to all namespaces or export every event message. Event occurrence counts are not included as a restart-rate calculation. Ask the owner to retain original evidence before normal event expiry, while keeping private resource names and messages within the incident boundary.

02

Compare the same container's current and earlier restart/termination observations

# 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: Two owner-retained, timestamped status projections identify the same UID/container. Compare restartCount and lastState reason/finish time. If the UID changed, start a separate comparison instead of subtracting unrelated counters. A stable count with a repeated BackOff event does not show a new process restart on every event.

This command reads one snapshot; it does not establish history or install a polling loop. Do not infer an exact backoff countdown or request rate from age fields. Review the admitted lifecycle policy and causal log privately if status lacks a reason. Readiness/application evidence remains necessary even if the current waiting field is blank.

Reproducible example

Check the input against the result

Input and result

Warning BackOff 10s kubelet Back-off restarting failed container api
# Source-shaped event; no kubelet restart was executed.
# Executed bounded owned HTTP/JSON controls, NOT a Kubernetes cluster:
owned_UID_filter: selected_events=1 other_same_name_events_excluded=1
constructed_event: reason=BackOff occurrences=4
separate_status_snapshots: restart_count_delta=0
root_cause_from_event_count=false native_kubelet_restarts=not_executed

Actual owned GETs returned two constructed status snapshots and an Event list. UID filtering selected the intended record and rejected an old same-name Pod. Four event occurrences coexist with a zero restart-counter difference in this fixture. This demonstrates why the records cannot be substituted for each other, not measured Kubernetes event aggregation, event expiry or recovery.

Evidence-led recovery

Correct only the demonstrated cause

Resolve the retained termination or health-check cause through its responsible owner, not the BackOff wrapper itself. Preserve the approved release and rollback procedure. Do not repeatedly delete Pods, clear events or alter cluster-wide kubelet retry settings to make an incident chart appear quieter.

Verify: Fresh status and normal service checks show the intended UID/container stable for the relevant failure interval, without additional terminations or restart-count growth. Identify any approved replacement UID explicitly and distinguish retained historical BackOff events from new ones. Verify availability, not simply that an event no longer appears.

Stop if: The event UID/container or causal termination cannot be recovered, timestamps come from unrelated observations, or a proposed action deletes workload/evidence, resets counters or changes retry behavior without reviewed application and availability context.

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 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 failed to start container: locate the runtime failure before expecting app logsA 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.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.