K8s Triage

---
name: k8s-triage
description: Use when a Kubernetes workload is unhealthy — pods CrashLoopBackOff / Pending / OOMKilled / ImagePullBackOff, a Deployment won't roll out, or a service returns 5xx after a deploy. Drives a read-only, evidence-first triage in a fixed order (workload → events → logs → scheduling/resources → networking) and reports the root cause, not a log dump.
---

# k8s-triage

Structured, read-only triage for a misbehaving Kubernetes workload. The goal is
to reach a *named root cause* with evidence, fast — not to dump everything and
guess. Optimized for the failure modes that actually bite in production, several
of which look like one thing and are really another.

## When to use

Reach for this whenever someone reports any of:

- a pod stuck in `CrashLoopBackOff`, `Pending`, `OOMKilled`, `ImagePullBackOff`, `ErrImagePull`, `CreateContainerError`
- a `Deployment` / `Statefulset` / `Rollout` that won't progress or is stuck `Degraded`
- a service that started returning `5xx`, timeouts, or "no healthy upstream" after a deploy or scale event
- "it was fine yesterday and now it's down" on a K8s-hosted service

Do **not** use it for cluster-provisioning, Helm authoring, or app-level business
bugs — this is incident triage of a running workload.

## Operating rules… install to load the full skill