Real Kubernetes error prompts: crash loops, OOM, ImagePull, denies, and slow APIs

Incidents do not arrive as clean runbooks. They arrive as Slack pings: “api is crashlooping,” “staging is slow,” “can you just delete everything in that namespace and start over?” The useful skill is turning that noise into a precise investigation or a bounded change — without improvising kubectl flags under adrenaline.

This playbook lists real error scenarios and the prompts we actually use with kprompt (and the kubectl equivalents you should still know). Every mutating path stays plan → safety → approve. Reads (explain, logs, describe, list, performance) run immediately. Software is experimental — practice on staging first.

How to read each scenario

• Symptom — what operators say or see
• Prompt — copy-pasteable kprompt line (swap names/namespaces)
• What you should get — findings, plan, or hard deny
• Do not — the shortcut that makes it worse

1. CrashLoopBackOff — “it keeps restarting”

Symptom: Pod Ready is false, restarts climb, Waiting reason CrashLoopBackOff. You need the last exit reason and logs — not a blind rollout restart.

kprompt "explain why api is crashing" -n staging
kprompt "logs api" -n staging
kprompt "describe api" -n staging

What you should get: explain findings such as CrashLoopBackOff, last exit reason, and a suggestion to inspect logs. If the underlying kill was OOMKilled, you may also see a suggested memory patch that still requires approval.

• Do — read Last State / findings before any mutate
• Do not — kubectl delete pod in a loop hoping the next one is healthier without reading why it died

2. OOMKilled — exit 137 / memory limit

Symptom: Last State Reason OOMKilled, exit 137, or explain reports OOMKilled on a container. Full deep-dive: OOMKilled guide.

kprompt "explain why payment-api is crashing" -n production
# If Suggested fix appears: read memory limit before→after → y or n

# Explicit follow-ups
kprompt "logs payment-api" -n production
kprompt "describe payment-api" -n production

What you should get: OOMKilled finding and optionally a plan to raise the Deployment memory limit. Approving applies a real patch — treat it like any production resource change.

• Do — confirm OOM in status; check metrics before doubling forever
• Do not — remove memory limits entirely to “make it stop”

3. ImagePullBackOff / ErrImagePull

Symptom: Pod never starts; Waiting Reason ImagePullBackOff or ErrImagePull. Usually a bad tag, private registry auth, or rate limit — not something a memory bump fixes.

kprompt "explain why api is not ready" -n staging
kprompt "describe api" -n staging
kprompt "logs api" -n staging   # often empty until the image pulls

What you should get: image-pull finding and a suggestion to verify the image reference / pull secrets. The fix is usually correcting the Deployment image or imagePullSecrets — a separate planned mutation or GitOps PR, not an auto-remediation guess.

• Do — read Events for the exact registry error
• Do not — scale up replicas of a Pod that cannot pull; you only multiply failures

4. Deployment not ready — “replicas unavailable”

Symptom: availableReplicas < desired; rollout stuck. Causes vary: probes, image pull, resources, PDB, bad config.

kprompt "explain why deployment api is not ready" -n staging
kprompt "list pods" -n staging
kprompt "describe api" -n staging

What you should get: a grounded chain over Deployment → ReplicaSet → Pods → Events → Logs style signals. After you know the cause, a separate prompt for rollback or scale — never combine “fix everything” into one unsupervised approve.

kprompt "rollback api" -n staging
kprompt "scale api to 3" -n staging --wait

5. “API is slow” — latency without a red Pod

Symptom: Pods look Ready; users feel p95 pain. kubectl describe will not show latency. With Prometheus configured, use a performance prompt.

kprompt "why is my api slow?" -n production
kprompt "show CPU for payment-api pods last hour" -n production

# Optional next: traces if Jaeger/Tempo is wired
kprompt "trace payment request" -n production

What you should get: read-only findings (CPU, memory, latency, HPA/replica signals) and optional scaling suggestions — still a plan if you mutate. If Prometheus is missing, the tool should fail clearly rather than invent metrics.

• Do — confirm Prom URL / access with kprompt tools first
• Do not — scale to 50 replicas because a chat model “felt” like load

6. Panic prompt — wipe / delete everything

Symptom: stress language — “delete all pods,” “wipe the namespace,” “remove the cluster.” These are the prompts that should fail closed.

kprompt "delete all pods in production"
kprompt "wipe the staging namespace"
kprompt "delete everything"

What you should get: risk denied — wipe-class and unscoped deletes never apply. Named delete of a single Pod, Deployment, or Service still shows a plan and needs approval.

kprompt "delete deployment redis" -n cache
# Plan + risk → y/N

7. Bad deploy — roll back under pressure

Symptom: error rate spiked after a rollout; you want last known good Revision, not a debate in the PR thread.

kprompt "explain why api is crashing" -n production
kprompt "rollback api" -n production
# Read plan: kubectl rollout undo … → approve
kprompt "rollback api" -n production --approve --wait --timeout 10m

What you should get: a medium-risk rollback plan with namespace and Deployment named. Use --approve only when you already reviewed the same prompt or gated JSON in CI.

8. Auth and kubeconfig failures

Symptom: CLI errors before any plan — missing kubeconfig, bad context, expired credentials, RBAC forbid. These are not “prompt engineering” problems; fix identity first.

# Fix credentials / context first, then:
kprompt config set context staging-cluster
kprompt "list deployments" -n staging

# Production — be explicit
kprompt "explain why api is down" -n production --context prod-cluster

What you should get on RBAC failures: a short message naming the verb/resource/namespace and a kubectl auth can-i hint — not a hallucinated successful plan.

Quick reference

Prompt habits that survive real incidents

• Name the workload and namespace — pronouns (“it”, “that thing”) burn time
• Read before mutate — explain/logs first on shared clusters
• One intent per approve — do not smuggle delete into a scale prompt
• Prefer staging rehearsal of the same prompt before prod --approve
• Keep PlanResult JSON when you need an audit trail (-o json)

Practice the playbook on staging

curl -fsSL https://kprompt.ai/install | bash
export KPROMPT_GEMINI_API_KEY="..."

kprompt "delete all pods" -n staging          # expect deny
kprompt "explain why api is crashing" -n staging
kprompt "scale api to 2" -n staging           # review plan → n or y

For the safety model behind denies and risk levels, see the safety post. For memory kills specifically, see the OOMKilled guide. For weird prompts that should fail closed or need extra care, see the edge-case prompt guide. The goal is simple: when the error is real, the prompt is boring — and the plan is visible.