What this prompt does
This prompt drives a methodical hunt for a memory leak in a Node.js [app_type] whose process grows from [start_memory] to [current_memory] over [time_period]. Instead of guessing, it asks the AI for a heap-snapshot comparison workflow using [profiling_tool], instrumentation to track allocations by module, a checklist of common leak patterns in [framework] (listener accumulation, closure leaks, timer leaks, stream backpressure), a low-overhead production diagnostic, GC analysis with --trace-gc and --max-old-space-size tuning, weak-reference patterns for caches, a load test that reproduces the leak faster, and growth-rate alerts. It focuses first on your [suspect_areas].
The structure works because memory leaks are slow, frustrating bugs where guessing wastes days. Anchoring the request to your real growth numbers and [suspect_areas] keeps the AI from offering generic advice, and the snapshot-comparison plus leak-reproducing load test are what actually pin the cause rather than just describing leaks in the abstract. The GC analysis with --trace-gc and the growth-rate alerts close the loop: the first shows whether memory is genuinely retained versus just slow to collect, and the second means the next leak is caught early instead of after another [time_period] of climbing.
When to use it
- A long-running Node process climbs in memory over hours or days until it is restarted or OOM-killed.
- You have heap snapshots but are not sure how to compare them to find the retained objects.
- You suspect event-listener accumulation, closures, timers, or stream backpressure but want a systematic check.
- You need a diagnostic safe enough to run in production without adding heavy overhead.
- You want a load test that surfaces the leak in minutes instead of waiting
[time_period]. - You want alerts on memory growth rate so the next leak is caught early.
Example output
Expect a step-by-step diagnostic plan rather than a single fix: how to capture and diff heap snapshots in [profiling_tool], instrumentation snippets for allocation tracking, a pattern-by-pattern checklist for [framework], a production-safe diagnostic script, GC flags to try, weak-reference cache examples, a load-test script that accelerates the leak, and monitoring alert definitions. The most likely culprit is investigated first based on your [suspect_areas].
Pro tips
- Give accurate
[start_memory],[current_memory], and[time_period]numbers — the growth rate guides how aggressive the diagnostics should be. - Be specific in
[suspect_areas](WebSocket connections, in-memory caches, connection pool) so the investigation starts where it is most likely to pay off. - Match
[framework]exactly, since leak patterns differ between Express, Fastify, and others, especially around middleware and lifecycle. - Use the weak-reference patterns for caches before adding manual eviction; unbounded caches are one of the most common causes.
- Run the leak-reproducing load test in staging first so you can iterate without disturbing production traffic.
- Iterate by feeding the AI an actual snapshot diff or
--trace-gcoutput to narrow down the retaining path.
