Unexplained memory growth on Heroku dyno during sustained load

The short answer

There is no fixed megabyte threshold that separates a leak from normal variance on Heroku — the signal is the trend, not the absolute number. A genuine leak shows monotonic RSS growth per unit of work that persists through idle periods and across multiple dyno cycles, eventually approaching your quota (and R14 errors). Normal variance is bounded jitter around a stable baseline, with periodic drops after garbage collection and a plateau once caches and runtime structures warm up.

Confirmed facts vs. likely explanation

Confirmed: Heroku reports only total container RSS via heroku ps:info and log-runtime-metrics. That number blends your application, the language runtime, OS page cache, and any other processes in the container. Swap allocation granularity per container is undocumented, so stable RSS can mask swap use.

Likely explanation for what you're seeing: sustained load inflates RSS through GC heap growth, JIT/runtime warmup, connection pools, and in-memory caches. Runtimes like the JVM, V8, and Ruby's allocator often grow toward available memory and resist returning it to the OS. This looks like a leak for hours, then plateaus. A real leak never plateaus.

Isolating app memory with Heroku-only metrics

Full separation isn't possible with platform metrics alone. The practical proxy:

1. Record RSS shortly after boot on a known dyno type and code version — that's your platform-plus-runtime baseline.
2. Sample heroku ps:info every few minutes for several hours under representative load, and plot RSS over time, annotating deploys and restarts so resets aren't mistaken for drops.
3. Introduce a controlled quiet period (route traffic away or pause the workload). If RSS declines toward baseline, the growth was working-set/cache behavior. If it stays elevated or keeps climbing afterward, you likely have retained memory — a leak.

Observing without triggering restarts

Avoid deploys, scaling changes, and manual restarts during the measurement window, since each resets RSS. Enable log-runtime-metrics and emit a low-rate in-app memory sample (e.g., process.memoryUsage() or equivalent) to stdout every 30–60 seconds — well under the 10,000-line/minute log drain limit. That gives you an app-only heap/RSS series to compare against the container total: if app heap is flat while container RSS climbs, suspect runtime/allocator behavior or swap rather than your code.

Caveats

Platform behavior can change, and swap accounting is undocumented — treat the baseline comparison as an estimate, and re-verify against current Heroku documentation if the numbers look anomalous. The one detail that would sharpen this diagnosis: does RSS ever plateau during a sustained quiet period, or does it rise until the dyno hits its quota?