Skip to main content
SnowOps Labs
All of the catalog
Injectable fault

OOMKilled: memory limit too low

echo-server pods keep restarting and the service is flapping. Restart counts climb; the kernel is killing the container the moment it allocates memory.

ResourcesHigh severityecho-server/echo-server
Definition on GitHub

What the symptom looks like

echo-server pods keep restarting and the service is flapping. Restart counts climb; the kernel is killing the container the moment it allocates memory.

Affects echo-server.

The hint ladder

Each hint narrows the search a little further. They are collapsed on purpose — open one only when you are properly stuck, because working out the next command yourself is the whole exercise.

Hint 1

The pods are restarting on a loop. `kubectl get pods -n echo-server` shows climbing RESTARTS — but *why* are they dying? `kubectl describe pod` and read the container's **Last State** carefully.

Hint 2

`Last State: Terminated, Reason: OOMKilled, Exit Code: 137`. The kernel is killing the container for exceeding its memory limit. So what *is* the limit? Check the deployment's `resources` block.

Hint 3

A 16Mi limit can't even hold a Go runtime. Compare with what the app actually needs (Grafana's container memory panels, or `kubectl top pod -n echo-server` on a healthy replica) and raise it: `kubectl -n echo-server set resources deploy/echo-server --limits=memory=256Mi --requests=memory=64Mi`.

Further reading

Related incidents

The incident field notes

One real Kubernetes failure a week — the symptom, the commands that found it, and the fix. Written from actual lab runs, not from memory.

You'll get the Kubernetes Incident Response Field Guide, plus occasional emails about new scenarios, posts and paid offerings such as courses and workshops. Unsubscribe any time.