Emire Barış · Member1 min readkubectl get pods explained: STATUS, restarts, and next commands
How to read kubectl get pods output — READY, STATUS, RESTARTS, AGE — what CrashLoopBackOff and Pending mean, and which kubectl command to run next.
kubectl get pods is usually the first command people learn — and the first place they get stuck. The table looks simple until STATUS says CrashLoopBackOff or Pending and RESTARTS climbs. This guide is how to read that table and what to run next.
Pods are the running instances; Deployments keep them alive. If those words are fuzzy, skim What is a Deployment and Pods vs Deployments first.
The columns
| Column | Meaning | What to check next |
|---|---|---|
| NAME | Pod object name (often Deployment hash + random suffix) | Do not treat as a stable app ID |
| READY | Ready containers / total containers in the Pod | 0/1 → probes, crashes, or not started |
| STATUS | Phase / reason (Running, Pending, CrashLoopBackOff, …) | describe + logs + events |
| RESTARTS | How often containers restarted | Climbing + CrashLoop → logs --previous |
| AGE | How long this Pod object has existed | Very new after a rollout is normal |
List Pods (namespace matters)
kubectl get pods
kubectl get pods -n staging
kubectl get pods -A
kubectl get pods -o wide -n stagingSTATUS values you will see first
- Running — containers started; still check READY if traffic fails
- Pending — not scheduled yet (resources, PVC, taints) → describe for Events
- CrashLoopBackOff — container keeps exiting → logs and --previous
- ImagePullBackOff / ErrImagePull — image name, tag, or registry auth
- Completed — Job/Pod finished successfully (normal for Jobs)
- OOMKilled (in describe/lastState) — memory limit hit
Deep dives when you are past the table: CrashLoopBackOff, ImagePullBackOff, OOMKilled.
Next commands (always)
From get pods → evidence
kubectl describe pod POD_NAME -n staging
kubectl logs POD_NAME -n staging --tail=200
kubectl logs POD_NAME -n staging --previous
kubectl get events -n staging --sort-by=.lastTimestamp | tail -40Prefer label selectors when a Deployment owns many Pods: kubectl get pods -l app=api -n staging. For live watching without retyping, K9s helps — then come back to kubectl for ticket-ready commands. See kubectl vs K9s.
Optional natural-language triage
Soft kprompt examples
kprompt "list pods in staging"
kprompt "explain why api pods are crashing" -n staging
kprompt "show events for api" -n stagingFor a full AI-assisted Pod loop without silent apply, see AI for Kubernetes Pods. For more kubectl patterns, see the natural-language cheat sheet.
Related posts
Kubernetes labels and selectors explained (the glue between objects)
Labels and selectors in Kubernetes: how Deployments label Pods, how Services find them, kubectl -l and endpoints checks, common mistakes, and optional kprompt examples.
Read articleKubernetes Service vs Deployment: roles, not rivals
Service vs Deployment in Kubernetes: Deployments run and update Pods; Services give those Pods a stable network identity. When you need each, how they connect via labels, and kubectl checks that stick.
Read articleWhat is a Deployment in Kubernetes? (with kubectl examples)
What a Kubernetes Deployment is, how it manages Pods and ReplicaSets, kubectl get/describe/rollout commands, common beginner mistakes, and optional natural-language checks with kprompt.
Read article