A service gets killed for running out of memory every couple of days. How do you investigate?

Confirm the pattern first from metrics: steady growth points to a leak or unbounded cache, while a sharp spike points to a single request loading too much at once. Capture a heap profile before and after a growth period and compare retained allocations. The usual causes are caches without eviction, growing collections held by long lived objects, unclosed resources, and endpoints that load an entire result set into memory.

The shape of the graph tells me where to look. A slow climb across days that survives quiet periods is a leak or a cache with no bound. A sawtooth that spikes on particular requests means something loads too much at once. For the first case I take heap profiles a few hours apart under similar traffic and diff them by retained size, then look at what holds the biggest objects. In practice it has usually been something boring: a map used as a cache with no eviction and no maximum, a metrics label built from a user supplied value so the cardinality grew forever, or listeners registered on a long lived object and never removed. For spikes I look for endpoints that read a whole table into a list rather than streaming, or a batch job that loads every row before writing. I hit exactly that with a CSV export that materialized a million rows; streaming it in pages made the memory flat. Afterwards I add an alert on the memory trend rather than only on the crash, so I hear about it before the restart does.