Introduction

When you are debugging a rollout or watching a failing deployment, running kubectl get pods once is rarely enough. Pod status changes quickly, and retyping the command every few seconds is inefficient.

The good news is that Kubernetes already gives you built-in ways to watch pod state. In most cases, you do not need a complicated script at all; a watch-based command or a small shell loop is enough.

Use kubectl --watch First

The simplest solution is the built-in watch flag.

kubectl get pods --watch

This keeps the command open and streams updates as pods are added, deleted, or change state. It is usually the right answer when you want a live view of pod status without writing any scripting logic.

You can scope it to a namespace too:

kubectl get pods -n payments --watch

If you only care about a subset of pods, combine it with a label selector:

kubectl get pods -n payments -l app=checkout --watch

That reduces noise and makes the output more useful during focused troubleshooting.

watch Command Versus --watch

Some developers reach for the shell watch utility:

watch -n 2 kubectl get pods -n payments

This reruns the whole command every two seconds and redraws the screen. It is different from kubectl --watch, which listens for changes from the Kubernetes API and streams them incrementally.

A rough guideline is:

• use kubectl --watch for native event-driven updates
• use shell watch when you want periodic redraws or need to combine multiple commands

Both are valid, but the built-in watch behavior is usually more efficient and more natural for pod status monitoring.

A Small Shell Loop When You Need Formatting Control

Sometimes you want a custom screen layout, timestamps, or a clear separator between refreshes. In that case, a shell loop is reasonable.

1#!/usr/bin/env bash
2
3namespace="payments"
4interval=3
5
6while true; do
7  clear
8  date
9  echo
10  kubectl get pods -n "$namespace" -o wide
11  sleep "$interval"
12done

This is not event-driven like --watch, but it gives you full control over presentation. It is useful when you want a dashboard-style view in a terminal.

Watching Specific Columns

For quick operational checks, custom columns can make the output much easier to scan.

kubectl get pods -n payments \
  -o custom-columns=NAME:.metadata.name,PHASE:.status.phase,NODE:.spec.nodeName \
  --watch

This avoids the default table when you only care about a few fields. It is especially useful in a busy namespace where the normal output has more columns than you need.

When You Need More Than Pod State

If the real goal is understanding why pods keep restarting or never become ready, kubectl get pods is only part of the picture. Pair it with other commands:

kubectl describe pod my-pod -n payments
kubectl logs my-pod -n payments --follow
kubectl get events -n payments --sort-by=.lastTimestamp

A pod watch tells you that something changed. Logs and events usually tell you why.

Example Helper Script

Here is a more practical wrapper that accepts a namespace and optional selector:

1#!/usr/bin/env bash
2
3namespace="${1:-default}"
4selector="${2:-}"
5
6if [[ -n "$selector" ]]; then
7  kubectl get pods -n "$namespace" -l "$selector" --watch
8else
9  kubectl get pods -n "$namespace" --watch
10fi

Usage:

./follow-pods.sh payments app=checkout

This keeps the script small while still making repeated debugging sessions faster.

Common Pitfalls

One common mistake is using a polling loop when kubectl --watch would already solve the problem more cleanly. Polling is fine, but it adds noise and repeated API calls.

Another issue is forgetting namespace scope. If the command appears to show nothing useful, you may be watching the default namespace while the workload lives somewhere else.

It is also easy to confuse kubectl get pods --watch with log streaming. Pod state updates and container logs are different streams. If you want application output, use kubectl logs --follow instead.

Finally, keep permissions in mind. A script can only watch resources that the current kubeconfig user is allowed to read.

Summary

• The simplest way to continuously follow pod state is kubectl get pods --watch.
• Use namespace and label filters to reduce output and focus on the pods you actually care about.
• The shell watch utility is useful for periodic redraws, but it is different from Kubernetes watch streaming.
• A small shell loop is reasonable when you want timestamps or a custom terminal layout.
• For root-cause analysis, combine pod watching with describe, logs --follow, and events.