## 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
```text
no pods found
```

## Steps
1. Test the selector directly with kubectl in the same namespace.
```bash
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.

2. Confirm which namespace and context stern is actually using.
```bash
kubectl config view --minify
stern --version
```
Expected: 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.
```bash
stern -n [NAMESPACE] -l [SELECTOR]
```
Expected: stern now finds the pods. This alone fixes most reports.

3. Check that your user can list pods and read logs in that namespace.
```bash
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.

4. Include pods that are not Running if yours recently restarted.
```bash
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.

5. As a sanity check, broaden the search once.
```bash
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