A .NET API's memory grows throughout the day and only drops after restart. How would you investigate?

How would you investigate memory growth in a production .NET service?

Gives a practical incident flow for memory growth using metrics, traffic correlation, heap evidence, and safe mitigation.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would start by confirming the pattern: process memory, managed heap size, GC counts, request volume, and recent deployments. If memory keeps growing after traffic settles or after full collections, I would suspect retained objects. I would look for correlations with specific endpoints, jobs, or payload sizes. If needed, I would capture a dump safely and compare retained object types and roots before changing code.

Full answer below

Practice focus

Production debugging, GC metrics, heap dumps, traffic correlation, mitigation, and root-cause discipline.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Sustained process growth can come from retained managed objects, intentional queues or caches, native memory, thread growth, or workload changes. Safe diagnosis correlates traffic and deployments with runtime counters, then captures focused heap evidence when needed.
I would start by confirming the pattern: process memory, managed heap size, GC counts, request volume, and recent deployments. If memory keeps growing after traffic settles or after full collections, I would suspect retained objects. I would look for correlations with specific endpoints, jobs, or payload sizes. If needed, I would capture a dump safely and compare retained object types and roots before changing code.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
My first goal is to protect the service while preserving evidence. I would check alerts, memory limits, restart history, traffic shape, and whether one route or job started producing larger objects. Then I would inspect runtime counters such as allocation rate, Gen 2 collections, LOH size, and thread count. If a dump is allowed, I would capture it during high memory and compare it to a healthier point. The root path matters more than the largest type name, because it tells me who is keeping objects alive.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Restarting repeatedly without collecting any evidence.
Looking only at total process memory.
Capturing dumps without considering sensitive data.
Changing random code before finding the retaining path.

A .NET API's memory grows throughout the day and only drops after restart. How would you investigate?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

Tech stacks

Skill areas

Suggest an improvement