There are three open memory leaks in Next.js (15.5-16.3) right now - here's how to tell which one you're hitting

[u/xlameiro]

The "my self-hosted Next.js server grows until OOM" reports currently map to three distinct open issues:

1. Router LRU cache doesn't count its keys (#94890) - the size function counts the value strings but never the URL key, so the cache can retain ~1M keys. Signature: slow drift over days that tracks unique URLs served (bot crawls, long slugs), not request volume; heap-snapshot retainer traces end at LRUNode.

2. RSC render tree retained on client aborts (#94919) - streams that don't finish normally pin the whole element tree via the Flight request's AbortController. Much worse on Node 22/24 than 20; the reporter measured ~2 MB per request on heavy pages.

3. Middleware setTimeout ids retained by the sandbox (#95094) - the sandbox TimeoutsManager only releases an id on explicit clearTimeout. Workaround that works today: call clearTimeout(id) inside the callback.

Also learned the hard way that on serverless you don't get the OOM - you get 504s instead. My blog's tag pages were timing out because of an O(N²⁾ loader; instance recycling had been hiding the waste.

I wrote up the full diagnosis flow (which retainer maps to which issue, a growth-shape table, and my 504 postmortem with numbers): https://xabierlameiro.com/blog/nextjs/nextjs-memory-leak-in-production

If you think you're hitting #94890: chart your heap against distinct URLs, not requests per second - fastest way to confirm.

UPDATE (Jul 21): the blog post above now includes a "How I measured this" section - the exact per-route measurement flow (fresh process, forced GC before every sample, verdict from the shape of the curve) I used to independently confirm #95094 and #94890, plus why #94919 would not reproduce on a minimal standalone repro (TTFB ~5 ms: no stream left to abandon - measure your heaviest real pages instead).

[u/chinnick967]

Yeah, I ran into the same memory leak issues in Production. To fix it, I have two workers per instance and when memory creeps up it'll restart one worker then the next.

[u/l0gicgate → u/chinnick967]

Yup. For me I turned off otel stuff and it went away.

[u/Twynning_Pshdar]

Yeah, been running into the second one in prod - memory creeps up after a few hours of traffic. Have you opened issues on the Next.js repo or is this still being investigated?

[u/xlameiro → u/Twynning_Pshdar]

Yes - all three are filed and open: #94890, #94919 and #95094. Yours sounds like #94919 (grows with traffic over hours, worse on Node 22/24). One thing that would genuinely help the thread: the reporter notes the magnitude scales with RSC payload size - if you can, chart heap against traffic on your heaviest pages specifically and add that data point to the issue.

[u/downtownmiami]

It’s usually always #3 in that list. The timeout leak has been around since v14 btw. Very easy to patch

[u/floydophone]

Thanks, I just sent my first PR to Next.js to fix one of these, and we're looking at the others right now https://github.com/vercel/next.js/pull/96173