Which memory metrics would you monitor for a production .NET service, and how would you alert on them?

Which memory metrics would you monitor for a .NET service?

Identifies useful memory and GC signals for alerting without overwhelming the team with noisy telemetry.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would monitor process memory, managed heap size, allocation rate, GC collection counts, GC pause or time in GC, and memory limit percentage if the service runs in a container or app service plan. For features with large payloads, I would also track request size, export size, and queue depth. Alerts need thresholds and duration so normal spikes do not page the team. I want alerts that point to action, such as memory approaching the limit or sustained growth without recovery.

Full answer below

Practice focus

Observability, GC counters, process memory, allocation rate, alert quality, and operational context.

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
Memory observability needs signal, not a dashboard full of numbers nobody trusts. The answer links metrics to actionable failure modes.
I would monitor process memory, managed heap size, allocation rate, GC collection counts, GC pause or time in GC, and memory limit percentage if the service runs in a container or app service plan. For features with large payloads, I would also track request size, export size, and queue depth. Alerts need thresholds and duration so normal spikes do not page the team. I want alerts that point to action, such as memory approaching the limit or sustained growth without recovery.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
The useful set depends on the hosting model. In containers, memory percent of limit is critical because the platform may kill the process. For .NET, allocation rate and Gen 2 activity help separate temporary pressure from long-lived pressure. Endpoint tags can show whether one route causes the spike. I would avoid alerting on every Gen 0 collection because that is normal. Better alerts combine trend, duration, and impact: memory high for ten minutes, restarts increasing, p95 latency rising, or queue processing falling behind.

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

Alerting on noisy counters without action guidance.
Ignoring container or hosting memory limits.
Tracking memory without route or job context.
Using only process working set as the whole story.

Which memory metrics would you monitor for a production .NET service, and how would you alert on them?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

Tech stacks

Skill areas

Suggest an improvement