Coding & Debugging Prompts

Memory Leak Investigation Planner

Build a measured investigation for rising memory usage, distinguish true leaks from pressure, and verify fixes with profiling evidence.

FreeClaudeChatGPT
Best for

Developers and site reliability engineers investigating gradual memory growth, crashes, or excessive garbage collection.

Suitable LLM groups
FrontierReasoning
Download Prompt.md
Prompt
You are a runtime performance engineer who specializes in memory leaks, allocation pressure, and resource-lifecycle defects.

Inputs:
1. Language, runtime, framework, and deployment model: {{runtime}}
2. Memory symptom and operational impact: {{symptom}}
3. Metrics, profiles, dumps, and logs: {{evidence}}
4. Relevant code paths and recent changes: {{code_context}}
5. Reproduction and production-safety constraints: {{constraints}}

Do the following:
1. Classify the symptom as a possible retained-object leak, native leak, unbounded cache, resource leak, fragmentation, allocation pressure, or expected working-set growth, and explain the evidence for each viable class.
2. Build a timeline connecting traffic, heap or resident memory, garbage collection, allocation rate, object counts, open resources, and deployments.
3. Rank retention hypotheses and specify the safest measurements needed to identify allocation and retention paths, including comparison snapshots or profiles.
4. Propose a minimal fix for the leading confirmed cause and distinguish it from temporary mitigations such as restarts or lower cache limits.
5. Deliver a reproduction plan, profiling procedure, code-level remediation options, before-and-after validation criteria, and production rollout safeguards. Do not claim a leak solely because memory does not immediately fall.

How to use

  1. Provide time-series memory and traffic evidence.
  2. Include heap profiles or object-count comparisons when available.
  3. Describe recent changes and long-lived caches.
  4. Profile safely in a representative staging environment first.

Example input

Runtime: Python 3.12 FastAPI service with four workers in Kubernetes. Symptom: resident memory grows from 420 MB to 1.8 GB per pod over nine hours, then pods are OOM-killed. Evidence: heap samples show increasing bytearray objects; growth correlates with large report downloads. Context: a recent feature buffers generated ZIP files in a module-level dictionary keyed by job ID; entries are removed only on successful download. Constraints: production profiling overhead must remain below 5%.

Example output

The evidence supports retained application objects rather than normal allocator behavior because bytearray counts and the module cache grow with report generation. The likely leak is failed or abandoned downloads that never remove cache entries. The plan confirms this with cache-size metrics and two heap snapshots, then replaces the dictionary with expiring storage and a finally-based cleanup path. Validation runs abandoned-download tests for 12 hours and requires a bounded cache, stable post-GC heap, and no throughput regression.

Customization tips

  • Separate heap memory from process resident memory.
  • Include garbage-collection and open-resource metrics.
  • State container limits and restart behavior.
  • Define the maximum acceptable steady-state memory.

Tags

#memory-leak#heap-analysis#runtime-profiling#performance-debugging#resource-management

FAQ

What is this prompt for?
It plans an evidence-based investigation of rising memory use and a validation strategy for the resulting fix.
How should I customize it?
Add runtime details, memory timelines, traffic patterns, profiles, dumps, recent changes, container limits, and reproduction constraints.
Are there any limitations?
Partial profiles may miss native allocations or production-only behavior, and memory retention is not always a true leak.
How is it different from a basic prompt?
It distinguishes leak classes, correlates allocation and retention evidence, and separates confirmed remediation from temporary mitigation.
Free

Configuration Drift Debugger

Find why software behaves differently across environments by comparing effective configuration, provenance, precedence, and runtime state.

ClaudeChatGPT
#configuration-drift#environment-debugging#devops
Free

Database Query Performance Investigator

Analyze a slow database query using execution evidence, data distribution, indexes, and workload constraints before recommending changes.

ClaudeChatGPT
#sql-performance#query-plan#database-indexing
Free

Production Code-Path Reconstructor

Reconstruct the code path behind a production incident by correlating requests, releases, traces, logs, configuration, and side effects.

ClaudeChatGPT
#production-debugging#incident-analysis#distributed-tracing
Related skills coming soon — browse all skills.
Related articles coming soon — visit the Learn hub.