| title | Human-Readable Error Name | |||
|---|---|---|---|---|
| error_message | The exact error string as it appears in kubectl / logs / events | |||
| category | pods | |||
| severity | High | |||
| recovery_time | 5–30 min | |||
| k8s_versions | 1.20+ | |||
| tags |
|
|||
| related |
|
Severity: High · Typical recovery time: 5–30 min · Affected versions: 1.20+
The exact error string, copied verbatim from `kubectl describe`, an event,
or a container log, so search engines and humans match it precisely.
One or two paragraphs, written from a production SRE's perspective: what this state actually means, what Kubernetes is doing when it reports it, and why it matters during an incident.
State the versions this behaviour applies to and note any version-specific differences (renamed fields, changed defaults, deprecated flags).
- Most common cause first
- Second cause
- Less common but important cause
flowchart TD
A[Symptom observed] --> B{Is the pod scheduled?}
B -- No --> C[Check FailedScheduling]
B -- Yes --> D{Container started?}
D -- No --> E[Check image / config]
D -- Yes --> F[Check application logs]
Confirm you are actually looking at this error and not a look-alike.
kubectl describe pod <pod> -n <namespace>
kubectl get events -n <namespace> --sort-by=.lastTimestamp
kubectl logs <pod> -n <namespace> --previousShow a representative, realistic snippet of what the commands above print
when this error is present.
- The fix that resolves the majority of cases
- Alternative fix
- Edge-case fix
Ordered, production-safe steps to restore service. Clearly mark any step that is disruptive (restart, rollout, delete) and explain the blast radius before recommending it.
How to confirm the fix worked (healthy status, passing probes, traffic served).
Configuration, limits, probes, policies, or CI checks that stop this recurring.
These free resources go deeper on AI-assisted Kubernetes troubleshooting: