Server
Memory leak
Memory leak is memory a process keeps holding after it no longer needs it, so usage rises with uptime until the process is killed or restarted. Restarting hides it for a while.
How it is measured
Plot resident memory (RSS) over days, not minutes. A leak shows as a staircase or slope that never returns to baseline between traffic peaks, and it resets to the baseline at every restart.
Confirm with a heap snapshot taken at two times, an hour apart, and compare object counts. The type whose count grows without bound is the suspect.
Worked example
A Node API starts at 180 MB after deploy and grows about 35 MB an hour. By hour 14 it reaches 700 MB, hits the container's 768 MB limit, and gets killed. The team's cron restart every 12 hours had kept this hidden for months.
Heap snapshots show 410,000 closures each holding a request object, created by an event listener added on every call and never removed. Removing the listener flattened the memory line at 190 MB.
How it differs
A memory leak is memory that is never released. A GC pause is the stall when the runtime tries to release memory it can. A leak excludes ordinary garbage that gets collected. A pause excludes unbounded growth by itself. Leaks cause longer pauses, and eventually an out-of-memory kill.
Common errors
Adding RAM instead of finding the cause. Using a daily restart as the permanent fix. Caching without a size limit. Adding event listeners or timers and never clearing them. Looking at heap use over an hour and concluding it is stable.
In practice
Graph RSS over a week for each service and look for slopes. If one climbs, take two heap snapshots and diff them. Put a size cap and expiry on every in-memory cache.