OOMKilled: finding the real memory ceiling
Exit code 137. The kernel's OOM killer ended the container because it hit its memory limit. The question that matters is whether the limit is wrong or the application is.
Run it
/k8s-triage checkout-worker keeps OOMKilling
What gets read
- Configured memory requests and limits on the container
- Restart count and the exit code / reason on the last terminated container
- Actual usage over time, if a metrics source is reachable from the cluster or your observability stack is documented in
CLAUDE.md - Whether the pod runs sidecars — Kubernetes 1.36's sidecar containers are accounted for separately from the main container's memory ceiling, and OpsKit is aware of that distinction
It tells you when it's flying blind
If OpsKit cannot reach Prometheus or Grafana, it notes the observability gap in its output instead of silently reasoning as if it had usage history. That's expected behavior, not a bug — don't assume a clean-looking report means metrics were available.
What it distinguishes
A limit set too low for a normal workload looks different in the evidence than a genuine memory leak (usage climbing monotonically across restarts) or a traffic spike (usage correlated with request volume). OpsKit's hypothesis names which pattern the evidence supports rather than defaulting to "increase the limit."
The fix
If the evidence points to an undersized limit, k8s-fixer opens a GitOps PR adjusting the manifest. If it points to a leak or a code-level issue, the investigation says so and stops there — that's not a manifest fix.
Limitations
OpsKit can't attach a heap profiler to a running process — it has no exec access by design. A genuine memory leak still needs your own profiling tools; OpsKit's job is ruling out the manifest and infrastructure explanations first so you're not profiling a config problem.
Ready to point it at your cluster?
Get OpsKit — $19