What RESTARTS 3 (5m ago) is actually counting

RESTARTS 3 (5m ago) is two separate facts about the whole pod, not one fact about one container.

• 3 is the sum of restartCount across every container in the pod, plus any restartable init containers — sidecars.
• (5m ago) is the most recent lastState.terminated.finishedAt of any of them.

The two numbers can therefore describe different containers, and on a multi-container pod they usually do. There is no pod-level restart field in the API for kubectl to read; the column is computed on the client every time you run get.

Where the numbers come from

kubectl get pod <pod> -o jsonpath='{range .status.containerStatuses[*]}{.name}{"\t"}{.restartCount}{"\t"}{.lastState.terminated.finishedAt}{"\n"}{end}'

Run against a two-container pod on 1.36.1 where both containers were crashing:

aaa-slow	6	2026-08-25T11:16:19Z
zzz-fast	7	2026-08-25T11:13:34Z

and kubectl get pod printed:

NAME        READY   STATUS             RESTARTS         AGE
bothcrash   0/2     CrashLoopBackOff   13 (2m46s ago)   11m

13 is 6 + 7. The 2m46s resolves to 11:16:19 — aaa-slow’s last exit, the more recent of the two. Neither container has restarted 13 times, and nothing restarted 2m46s ago that accounts for all 13.

Zoom

Why this matters more than it sounds

A single hot container hides behind a quiet pod. A pod with eight containers, one of which restarts every few minutes, shows a steadily climbing number that looks like general instability. It is one sidecar. Conversely, a count of 40 on a pod you know has four containers is not necessarily forty crashes of your app.

The bracketed time is not the age of the count. RESTARTS 40 (2s ago) does not mean forty restarts in the last few seconds. It means the count is forty and the latest one was two seconds ago. The forty could span a week. This reads as an emergency during an incident and frequently is not one — or, worse, reads as fine when the real signal is that the rate just changed.

The rate is the signal, not the total. A count of 300 that has not moved in a day is a historical fact. A count of 3 that was 1 an hour ago is an active problem. The column shows you the total and one timestamp, which is exactly enough to tell those apart if you look at the brackets, and not enough if you only read the number.

Zoom

Sidecars count, and they count before the pod is ready

An init container with restartPolicy: Always — a sidecar, on by default since 1.29 and reporting as a graduated feature on the 1.36 cluster this was checked against — has a restart count that is included in the pod’s total. It is included even while the pod is still initialising:

NAME      READY   STATUS                  RESTARTS       AGE
sidecar   1/2     Init:CrashLoopBackOff   7 (117s ago)   12m

That is a pod whose init container has restarted seven times while the main container has never started. Ordinary init containers, the run-to-completion kind, also contribute their restarts while they are running. If you are counting restarts to decide whether an application is unstable, a crash-looping sidecar will make an application that has never even been reached look unstable.

Reading it correctly

Per container, which is what you almost always want:

kubectl get pod <pod> -o custom-columns='NAME:.metadata.name,CONTAINER:.status.containerStatuses[*].name,RESTARTS:.status.containerStatuses[*].restartCount'

The reason for the most recent exit, which is the other half of the story:

kubectl get pod <pod> -o jsonpath='{range .status.containerStatuses[*]}{.name}{"\t"}{.lastState.terminated.reason}{"\t"}{.lastState.terminated.exitCode}{"\n"}{end}'

A count with no reason is not actionable. OOMKilled and Error are entirely different investigations, covered in OOMKilled and exit code 137 and how to fix CrashLoopBackOff respectively.

The counter is not durable

restartCount lives in the pod’s status. Delete the pod — or let a Deployment replace it — and the count starts at zero on the new one. It is not a property of the Deployment, the ReplicaSet or the application. This is why “restarts across the fleet” cannot be answered from kubectl get pods after a rollout, and why an alert on the absolute value silently resets every time you deploy.

It also means the count is a poor incident record. If you want to know how many times something crashed last Tuesday, the pod that did it is gone. Events and the kube_pod_container_status_restarts_total metric survive the pod; the column does not.

What to do with it

• Alert on the delta, not the total. increase(...[15m]) > 0 catches the pod that started failing. A threshold on the absolute count catches pods that have been up a long time.
• Expand to per-container before drawing a conclusion. The pod-level number is a summary, and summaries of small numbers of very different things are misleading.
• Pair it with lastState.terminated.reason every time. The count says something happened; only the reason says what.
• Watch pods whose count is not moving but is high. A container that restarted 200 times and then settled usually means something external recovered — a dependency, a DNS entry, a secret — and that dependency will break again.

For how the STATUS column next to it is derived, which follows similar rules and has similar surprises, see how kubectl computes a pod’s STATUS.