Introduction

kubectl get ... -o jsonpath=... is useful when you need one exact status field instead of the full default table. The important part is knowing whether you want pod-level status, such as Running, or container-level status, such as readiness, restart count, waiting reason, or exit code.

Those are different paths in the Kubernetes object. If you query the wrong level, you can get a technically correct answer that still hides the actual problem.

Start With Pod Phase

If you only need the overall pod phase, query .status.phase.

kubectl get pod my-pod -o jsonpath='{.status.phase}'

Typical output might be:

Running

This is useful for a quick health check, but it is not enough when one container inside the pod is crashing or not ready.

Query Multiple Pod Phases

If you want a compact list of pod names and their phases:

kubectl get pods -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.phase}{"\n"}{end}'

That is a common scripting pattern because it avoids parsing the full JSON output externally.

Container Status Lives Under containerStatuses

Detailed container information is stored in .status.containerStatuses. If a pod has multiple containers, each one has its own readiness flag, restart count, and current state.

To print the readiness of the first container:

kubectl get pod my-pod -o jsonpath='{.status.containerStatuses[0].ready}'

To print the name and readiness of every container:

kubectl get pod my-pod -o jsonpath='{range .status.containerStatuses[*]}{.name}{"\t"}{.ready}{"\n"}{end}'

This is often more useful than .status.phase, because a pod can be in Running phase while one container is unhealthy.

Waiting Reasons And Exit Codes

When you are debugging a failing pod, waiting and termination reasons are often the real answer. Those values live under .state.waiting and .state.terminated.

Get the waiting reason of the first container:

kubectl get pod my-pod -o jsonpath='{.status.containerStatuses[0].state.waiting.reason}'

Get the termination reason and exit code:

kubectl get pod my-pod -o jsonpath='{.status.containerStatuses[0].state.terminated.reason}{"\t"}{.status.containerStatuses[0].state.terminated.exitCode}'

These are the fields that tell you whether you are dealing with CrashLoopBackOff, image pull problems, or a process exiting with a nonzero code.

Restart Count Is Often The Fastest Signal

Restart count is one of the quickest ways to see whether a pod looks stable:

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

A pod may still be technically running while a container restarts repeatedly, so restart count is worth checking early.

Namespace And Discovery Matter

If the pod is not in the default namespace, include the namespace explicitly:

kubectl get pod my-pod -n payments -o jsonpath='{.status.phase}'

When you are unsure about the path, inspect the full object:

kubectl get pod my-pod -o json

Finding the exact field in the full JSON is usually faster than guessing nested JSONPath expressions from memory.

When jsonpath Stops Being Pleasant

kubectl JSONPath is convenient for direct field extraction, but it becomes awkward when you want complex filtering inside nested arrays, especially by container name. If you reach that point, jq, -o go-template, or a small script may be clearer than forcing more complexity into jsonpath.

That is not a failure of the command. It is simply the point where a lightweight extraction tool stops being the best tool.

Common Pitfalls

One common mistake is checking only .status.phase and assuming the pod is healthy. Another is forgetting that container details live under .status.containerStatuses, not directly under .status. Developers also often query the wrong namespace and then conclude the pod or field is missing. Finally, some scripts try to make kubectl JSONPath do deep filtering that jq would handle much more cleanly.

Summary

• Use .status.phase for the overall pod phase.
• Use .status.containerStatuses for readiness, restart counts, waiting reasons, and exit codes.
• Include -n namespace when the pod is not in the default namespace.
• Inspect the full JSON when building a new JSONPath expression.
• Switch to jq or templates when nested filtering becomes too awkward for kubectl JSONPath.