stern "no pods found" with a valid selector: what to check
Fixes stern reporting no pods found even though the selector looks right. Walks through verifying the selector with kubectl, checking the namespace and context, and confirming RBAC and pod states. Reach for it when stern finds nothing but you know the pods exist.
TL;DR
Stern only watches the namespace in your current context and only matches Running pods by default. Verify the exact selector with kubectl get pods, confirm the namespace, and check RBAC; one of those three is wrong in nearly every case.
Verbatim error
no pods foundSteps
- Test the selector directly with kubectl in the same namespace.
kubectl get pods -n [NAMESPACE] -l [SELECTOR]Expected: this lists the pods you expect stern to tail. If kubectl also finds nothing, the selector or namespace is wrong; fix it here first, because stern cannot find what kubectl cannot see.
- Confirm which namespace and context stern is actually using.
kubectl config view --minify
stern --versionExpected: the current context's namespace matches where your pods live. Stern defaults to the context namespace, not to default, and not to all namespaces. If they differ, pass the namespace explicitly.
stern -n [NAMESPACE] -l [SELECTOR]Expected: stern now finds the pods. This alone fixes most reports.
- Check that your user can list pods and read logs in that namespace.
kubectl auth can-i list pods -n [NAMESPACE]
kubectl auth can-i get pods/log -n [NAMESPACE]Expected: both answer yes. A no on either means RBAC is the blocker; stern fails silently instead of printing a forbidden error in some versions.
- Include pods that are not Running if yours recently restarted.
stern -n [NAMESPACE] -l [SELECTOR] --include "[POD-PREFIX].*"Expected: stern also tails completed or crashlooping pods matching the pattern. By default stern skips non-running pods, so a CrashLoopBackOff workload looks like no pods found.
- As a sanity check, broaden the search once.
stern -n [NAMESPACE] --all-namespaces -l [SELECTOR]Expected: if pods appear only with --all-namespaces, you were looking in the wrong namespace all along. Narrow back down once confirmed.
When to use
- stern prints no pods found but the selector looks correct
- Stern worked before and stopped after a context or namespace switch
- You are tailing logs across a new cluster or a new namespace
When not to use
- stern finds pods but shows no logs; that is a logging pipeline issue, not selection
- kubectl also finds no pods; fix the selector or the workload first
- You need logs from a previous container instance; use kubectl logs -p instead
Why it happens
Stern builds its watch from your kubeconfig context: one cluster, one namespace, one label selector. Any mismatch in that triple, a typo in the selector, the wrong namespace in the context, or a context pointing at the wrong cluster, yields an empty watch, which stern reports as no pods found.
Edge cases
- Selectors with special characters need quoting; the shell can mangle matchLabels with dots or slashes before stern sees them.
- Very new pods may not appear until the API server cache catches up; retry after a few seconds rather than assuming failure.
- Multiple kubeconfig files merged in KUBECONFIG order can silently change the current context; check which file wins.
- Stern templates that filter by container name can hide pods whose containers were renamed in the last deploy.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst__UvA5Ag9LlOgcXRWx5aIfQ