How to fix server is approaching the used memory threshold in nextjs

If you've run a Next.js app in production long enough, you've probably seen a warning like this show up in your server logs:

Server is approaching the used memory threshold

The instinctive fix is to throw more memory at the problem — bump up Node's heap allocation and move on. That's what I tried first. It didn't fix anything. What actually solved it was something much simpler: deleting the .next folder and rebuilding from scratch.

Here's what happened, and why the "obvious" fix wasn't the right one.

The Problem

The app was running fine for weeks, then started throwing memory warnings under normal traffic — nothing unusual, no sudden spike in usage, no new heavy dependency. Just a server that was slowly creeping toward its memory ceiling and eventually warning that it was approaching the threshold.

The natural assumption: Node's default heap size wasn't enough for the app anymore.

First Attempt: Increase the Heap Allocation

Node.js has a default memory limit for the V8 heap, and it's common practice to raise it for larger applications using the --max-old-space-size flag:

bash

NODE_OPTIONS="--max-old-space-size=4096" next start

Or, if you're setting it in package.json:

json

{
  "scripts": {
    "start": "NODE_OPTIONS='--max-old-space-size=4096' next start"
  }
}

This is a legitimate fix for a lot of memory issues — genuinely memory-hungry apps, large data processing, heavy in-memory caching, etc. In this case, though, it changed nothing. The warning came back at roughly the same point it always had, just with a higher ceiling to climb toward.

That was the first sign this wasn't a "the app needs more memory" problem. It was a "something is holding onto memory it shouldn't" problem.

The Actual Fix: Delete `.next` and Rebuild

The .next directory is Next.js's build output — compiled pages, cached build artifacts, webpack chunks, and incremental build cache used to speed up future builds. It's meant to be disposable; deleting it and rebuilding is always safe.

bash

rm -rf .next
next build
next start

After a clean rebuild, the memory warnings stopped completely. No config changes, no dependency updates — just a fresh build.

Why This Actually Worked

The most likely explanation is a stale or corrupted build cache. Next.js's incremental build system reuses cached artifacts between builds to speed things up, but that cache can accumulate cruft over time — especially across multiple deployments, dependency updates, or interrupted builds. A stale cache can cause the server to hold onto more in-memory state than it should, or to load duplicate/orphaned chunks that never get garbage collected properly.

Increasing the heap size doesn't fix that — it just gives the leak or bloat more room to grow before it becomes visible again. A clean .next rebuild removes the bad cache entirely, so the server starts from a known-good state.

Takeaways

A few things I'd keep in mind next time this comes up:

Don't reach for --max-old-space-size as the first move. It's a real tool, but it treats the symptom. If the memory usage grows steadily rather than being consistently high from the start, that pattern points more toward a cache/leak issue than a genuine "not enough memory" issue.
.next is disposable — treat it that way when debugging. If you're seeing weird runtime behavior after a deploy (memory creep, stale content, odd hydration errors), clearing the build cache and rebuilding is a cheap, safe thing to try early, not late.
Watch for the pattern, not just the warning. A memory warning that reappears at the same threshold after you've raised the ceiling is a strong signal you're not actually memory-constrained — something is accumulating.
If this becomes a recurring issue, it's worth automating a clean rebuild step (rm -rf .next before next build) in your CI/CD pipeline rather than relying on incremental builds indefinitely, especially if you deploy frequently.

Sometimes the fix isn't "give it more resources" — it's "give it a clean slate."

Loading