How to find a Next.js memory leak in production

xabierlameiro.com — Sat, 18 Jul 2026 01:58:24 +0000

Originally published at xabierlameiro.com.

If your self-hosted Next.js server grows until it dies with FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory - or the container gets OOMKilled (exit code 137) - don't start by auditing your own code. As of July 2026 there are three documented memory leaks open in the framework itself, spanning Next.js 15.5 to 16.3.

Leak 1: the router LRU cache doesn't count its keys

#94890 - the route-resolution cache's size function adds up the value strings but never the URL key, so it can retain ~1M keys (hundreds of MB) while believing it is tiny. Signature: slow heap drift over days that tracks unique URLs served (bot crawls, long slugs), not request volume; heap-snapshot retainer traces end at LRUNode. Tip: chart your heap against distinct routes, not requests per second.

Leak 2: the RSC render tree is retained on client aborts

#94919 - streams that don't finish normally (mobile clients, crawlers, users navigating away) pin the whole element tree via the Flight request's AbortController. Much stronger on Node 22/24 than 20; the reporter measured ~2 MB per request on heavy pages. Mitigation while it stays open: trim the RSC payload of your heaviest pages.

Leak 3: middleware setTimeout ids retained by the sandbox

#95094 - the sandbox TimeoutsManager only releases a timeout id on explicit clearTimeout. A one-line workaround that works today:

const timeoutId = setTimeout(() => {
    fireAndForgetWork();
    clearTimeout(timeoutId); // releases the id from the sandbox manager
}, 0);

Which one are you hitting?

Growth shape	Correlates with	Suspect
Slow, monotonic drift over days	Unique URLs (bots, long slugs)	Router LRU cache (#94890)
Proportional to traffic; worse on heavy pages	RSC payload and client aborts	RSC tree retention (#94919)
Steps the GC never recovers	Requests through middleware	Sandbox timeouts (#95094)
No OOM, but sporadic 504s on serverless	Render cost, not memory	Your render is expensive

To confirm: start with NODE_OPTIONS='--inspect' next start, take two heap snapshots separated by load, and read the retainers in Chrome DevTools' Memory tab.

On serverless the leak wears a disguise

You don't get the OOM - you get 504s. My blog's tag pages were timing out with FUNCTION_INVOCATION_TIMEOUT because of an O(N^2) post loader (a ~32-second render against a ~10-second limit); instance recycling had been hiding the waste. The fix was a module-level cache: memory spent on purpose, bounded and static per deploy.

The full diagnosis flow - which retainer maps to which issue, the exact docs commands, and my 504 postmortem with before/after numbers - is in the original post: https://xabierlameiro.com/blog/nextjs/nextjs-memory-leak-in-production

How document my react components with JSDoc

xabierlameiro.com — Thu, 19 Jan 2023 18:55:44 +0000

It is necessary to have a good documentation about our components, so that other developers can understand how it works and how to use it. In this article we are going to see how we can document our react components with JSDoc and how to publish the documentation in our static site.

With a few simple steps, the jsdoc library and the use of good programming practices when working with react, we will be able to have a documentation of our components automatically. There are different plugins to upgrade our jsdoc and support react, but as React is still javascript and the components functions the default lib is more than enough.

The report we are going to generate is still an html file, so you can deploy it in any static site

More details here : How document my react components with JSDoc