How to Monitor JavaScript Memory Leaks in Production

Remember when JavaScript was just for making snowflakes fall on your GeoCities page? Those were simpler times. Now we’re building entire applications in the browser, and surprise! JavaScript wasn’t exactly designed with memory management in mind. While other languages have garbage collectors that actually, you know, collect garbage, JavaScript’s garbage collector is more like that roommate who promises to clean but just shoves everything under the bed.

The real kicker? Most of the advice out there tells you to “just open Chrome DevTools and check the Memory tab.” Great advice… if your users are willing to open DevTools while shopping on your site. Spoiler alert: they’re not.

So let’s talk about how to catch memory leaks in production, where the real disasters happen.

Why JavaScript Memory Leaks Are Like That Friend Who Never Leaves

JavaScript memory leaks are special. In other languages, when you’re done with something, you can explicitly tell the computer “hey, we’re done here, clean this up.” JavaScript? It’s more like hosting a party where you have to hope your guests figure out when to leave on their own.

Here’s what typically goes wrong:

• Global variables everywhere - Because who doesn’t love accidentally attaching things to window?
• Event listeners that won’t let go - Like that ex who still likes all your Instagram posts
• Timers running forever - setInterval is the gift that keeps on giving (memory leaks)
• Closures holding onto everything - JavaScript’s way of being overly sentimental about data

The worst part? In development, you restart your browser every few minutes. Your users? They keep 47 tabs open for three weeks straight. That’s when the fun really begins.

The performance.memory API: JavaScript’s Deprecated Attempt at Self-Awareness

Once upon a time, Chrome gave us performance.memory, and we thought our problems were solved. It looked so simple:

console.log(performance.memory);
// {
//   totalJSHeapSize: 29400000,
//   usedJSHeapSize: 15200000,
//   jsHeapSizeLimit: 1530000000
// }

“Great!” we thought. “Now we can monitor memory usage!” Then reality hit:

1. It only works in Chrome (sorry, Firefox and Safari users)
2. It’s deprecated (because of course it is)
3. The numbers it gives you are about as accurate as a weather forecast
4. MDN literally tells you not to use it in production

While heap memory limits are the primary concern for JavaScript applications, recursive functions that consume excessive call stack memory will cause Maximum call stack size exceeded errors before reaching heap limits, making call stack monitoring equally important.

But hey, at least it exists, right? That’s more than we can say for most JavaScript memory monitoring solutions.

How to Monitor JavaScript Memory in Production (Without Crying)

Since we can’t rely on browser APIs that actually work consistently (thanks, browser vendors!), we need to get creative. Here’s a practical approach that won’t make you want to switch careers:

Step 1: Accept What You Can Monitor

If you’re stubborn enough to use performance.memory despite everyone telling you not to, here’s a production-ready approach:

if ("performance" in window && performance.memory) {
  const memoryCheckInterval = setInterval(() => {
    const memoryUsage = performance.memory.usedJSHeapSize / performance.memory.jsHeapSizeLimit;

    if (memoryUsage > 0.9) {
      // We're using 90% of available memory - time to panic
      console.warn(`Memory usage critical: ${Math.round(memoryUsage * 100)}%`);

      // Log to your monitoring service
      if (window.TrackJS) {
        TrackJS.track(new Error(`High memory usage detected: ${Math.round(memoryUsage * 100)}%`));
      }

      // Only alert once per session
      clearInterval(memoryCheckInterval);
    }
  }, 10000); // Check every 10 seconds
}

Note: performance.memory returns an object that doesn’t serialize nicely with JSON.stringify because JavaScript loves making simple things complicated.

Step 2: Track What Actually Matters

Since we can’t reliably measure memory across all browsers, let’s track symptoms instead of the disease:

let lastDOMNodeCount = 0;
setInterval(() => {
  const currentNodes = document.getElementsByTagName('*').length;

  if (currentNodes > lastDOMNodeCount * 1.5 && currentNodes > 1000) {
    // DOM is growing suspiciously fast
    TrackJS.track(new Error(`DOM bloat detected: ${currentNodes} nodes`));
  }

  lastDOMNodeCount = currentNodes;
}, 30000); // Check every 30 seconds

// Track suspicious object growth
const objectCounts = new Map();

function trackObjectCreation(className, instance) {
  const count = (objectCounts.get(className) || 0) + 1;
  objectCounts.set(className, count);

  if (count > 1000) {
    TrackJS.track(new Error(`Possible memory leak: ${count} ${className} instances`));
  }

  return instance;
}

// Usage in your code
class PotentiallyLeakyThing {
  constructor() {
    trackObjectCreation('PotentiallyLeakyThing', this);
    // ... rest of your constructor
  }
}

Common JavaScript Memory Leak Patterns (And How to Avoid Them)

Let’s look at the usual suspects that turn your web app into a memory-eating monster:

The “Accidental Global” Classic

// The bad way (creates a global variable)
function doSomething() {
  superImportantData = new Array(1000000); // Oops, forgot 'let'
}

// The good way
function doSomething() {
  let superImportantData = new Array(1000000);
}

The “Event Listener Hoarder”

// The bad way (listener never removed)
document.getElementById('button').addEventListener('click', function() {
  // This anonymous function can never be removed
  expensiveOperation();
});

// The good way
const button = document.getElementById('button');
const handleClick = function() {
  expensiveOperation();
};

button.addEventListener('click', handleClick);

// Later, when cleaning up
button.removeEventListener('click', handleClick);

The “setInterval That Won’t Die”

// The bad way
setInterval(() => {
  updateSomething();
}, 1000);
// This runs forever, even after the component is gone

// The good way
const intervalId = setInterval(() => {
  updateSomething();
}, 1000);

// Clean up when done
clearInterval(intervalId);

The “Closure Memory Trap”

This one’s my favorite because it’s so sneaky:

// The bad way
function createLeak() {
  const hugeData = new Array(1000000).fill('leak');

  return function() {
    console.log('I don\'t even use hugeData!');
    // But this closure still holds onto hugeData
  };
}

// The good way
function noLeak() {
  let hugeData = new Array(1000000).fill('data');

  // Use the data
  processData(hugeData);

  // Clear the reference
  hugeData = null;

  return function() {
    console.log('Much better!');
  };
}

Framework-Specific Memory Leak Detection

React Memory Leaks (useEffect Strikes Back)

React developers love useEffect, but useEffect doesn’t always love them back:

// The bad way
useEffect(() => {
  const timer = setInterval(() => {
    setSomeState(prev => prev + 1);
  }, 1000);
  // Forgot to clean up!
});

// The good way
useEffect(() => {
  const timer = setInterval(() => {
    setSomeState(prev => prev + 1);
  }, 1000);

  return () => clearInterval(timer); // Cleanup function
}, []);

Vue.js Memory Management

Vue usually handles cleanup well, but third-party libraries can trip you up:

// The bad way
mounted() {
  this.chart = new FancyChart(this.$refs.chartContainer);
}

// The good way
mounted() {
  this.chart = new FancyChart(this.$refs.chartContainer);
},
beforeDestroy() {
  if (this.chart) {
    this.chart.destroy(); // Don't forget to clean up!
    this.chart = null;
  }
}

Angular and the RxJS Subscription Apocalypse

Angular developers know the pain of subscription management:

// The bad way
ngOnInit() {
  this.userService.getUser().subscribe(user => {
    this.user = user;
  });
  // This subscription lives forever
}

// The good way
private destroy$ = new Subject<void>();

ngOnInit() {
  this.userService.getUser()
    .pipe(takeUntil(this.destroy$))
    .subscribe(user => {
      this.user = user;
    });
}

ngOnDestroy() {
  this.destroy$.next();
  this.destroy$.complete();
}

Production Memory Monitoring Best Practices

After years of fighting JavaScript memory leaks (and losing), here’s what actually works:

1. Sample Smart, Not Hard

Don’t check memory every millisecond. Your monitoring shouldn’t cause the problems it’s trying to detect. Check every 5-10 seconds during normal activity, maybe more frequently during critical operations, but don’t go overboard.

2. Set Realistic Thresholds

Every app is different. Monitor for a week to establish baselines:

• Warning: 70% of heap limit
• Critical: 85% of heap limit
• Growth rate: Alert if memory grows >10% per hour

3. Correlate with User Actions

Memory spikes aren’t always leaks. Track what users are actually doing:

// Log memory usage with user actions
function trackAction(actionName) {
  const memoryUsage = performance.memory ?
    Math.round(performance.memory.usedJSHeapSize / 1048576) :
    'unknown';

  console.info(`Action: ${actionName}, Memory: ${memoryUsage}MB`);
  // TrackJS will automatically capture this as telemetry for any errors
}

The Future of JavaScript Memory Monitoring (Spoiler: It’s Complicated)

The browser vendors are working on performance.measureUserAgentSpecificMemory(), which promises to be better than performance.memory. The catch? It requires cross-origin isolation, which is about as easy to implement as teaching your cat to do taxes.

For now, we’re stuck with:

• Chrome: Deprecated but functional APIs
• Firefox: “What’s memory monitoring?”
• Safari: “Security says no”

Conclusion: Embrace the Chaos

JavaScript memory management is like JavaScript itself: quirky, unpredictable, and somehow still running most of the internet. The key to production memory monitoring isn’t finding the perfect solution (it doesn’t exist), but building a system that’s good enough to catch problems before your users do.

Remember:

• Monitor what you can (even if it’s not perfect)
• Track symptoms when you can’t track causes
• Set up alerts before things get critical
• Clean up after yourself (your future self will thank you)

And most importantly, accept that JavaScript will always find new and creative ways to leak memory. It’s not a bug, it’s a feature! (It’s definitely a bug.)

Want to make memory monitoring easier? TrackJS can help you track those pesky memory errors and correlate them with real user sessions. Check out our memory monitoring documentation for ready-to-use code snippets. Because if you’re going to fight JavaScript memory leaks, you might as well have some help.

Have a creative memory leak detection technique? Found a new way JavaScript is hoarding memory? Drop us a line. We collect JavaScript horror stories like JavaScript collects memory leaks.