A memory leak is a bug where software claims memory to do its work but never gives it back, even after that memory is no longer needed. Each run leaves a bit more memory locked up, so the available space shrinks over time. Eventually the program slows to a crawl or runs out of memory and crashes.
Imagine a kitchen where every dish that comes back dirty goes into the sink, but nobody ever washes up. For a while there are still clean plates in the cupboard. But the pile keeps growing, and at some point service grinds to a halt because there is nothing left to serve on. A memory leak works the same way: small and invisible at first, then suddenly a real problem. This is the kind of bug that hides for days because it only shows up under sustained, real-world load.
A common culprit is something kept around longer than expected: an event listener that is added but never removed, or a list that quietly grows on every request and is never trimmed. The code looks correct in isolation, which is what makes leaks slippery.
Leaks are most painful in software that runs continuously, like a web server or a background service, because the memory is never freed by a restart. Finding them is a standard part of debugging: developers use profiling tools to watch memory grow over hours and trace it back to the exact code that forgot to clean up.
At TopDevs we run performance tests under realistic load before launch, so leaks surface in our environment rather than on a Saturday night in production.
