Scenario: a Node.js Pod gets OOMKilled every 6 hours Intermediate
Estimated reading time: 1 min read
RSS climbs steadily, the Pod dies with exit code 137 without a single error line in the logs, and it repeats 6 hours later.
You go through four decisions: the first action, reading the heap snapshot, fixing the leak, and adding guardrails so next time it is caught within hours instead of two weeks.
- If you pick wrong, read the explanation and Choose again.
- Only your first choice at each step counts toward the score. Hint: in step 2, read the Size Delta and Retainers columns before reading the warning.
NestJS Pods get OOMKilled every 6 hours
You are a backend dev on the catalog API team (NestJS, Node 24, 6 Pods, memory limit 1536Mi). Every choice shows its consequences right away on the metrics below.
Step 1/4 · Exit code 137, not a single stack trace
For two weeks, every Pod has restarted roughly once every 6 hours. The RSS graph is a steady ramp from 350 MB to just under 1.5 GB. In the last hour before each restart, p99 climbs from 180 ms to nearly 1 second, then 502s appear when the Pod dies.
kubectl logs --previous shows only normal access logs; the last line has no error at all. The team suggests a few directions.
- exit code
- 137 = 128 + 9 (SIGKILL)
- RSS
- +~200 MB/hour, never goes down
- CPU in the last hour
- 35% → 80% (mostly GC)
- traffic
- stable, no spikes
$ kubectl describe pod catalog-api-6d8f-x2k9p
Last State: Terminated
Reason: OOMKilled
Exit Code: 137
Restart Count: 9
Limits:
memory: 1536MiWhat do you do?
When you finish, read Common performance mistakes for real measurements of an unbounded Map cache and per-request listeners on Node 24.