A production .NET service crashed with OutOfMemoryException and restarted. What would you do next?

What would you do after a .NET service crashes with OutOfMemoryException?

Practices incident response after an OOM: restore service, collect evidence, identify trigger, and prevent recurrence.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I would first make sure the service is healthy after restart and users are not still affected. Then I would gather evidence: logs, memory metrics before the crash, traffic, recent deployments, endpoint mix, job activity, and any available dump or crash artifact. I would check whether the OOM happened on one instance or many. If a specific feature or job triggered it, I would limit or disable that path while investigating.

Full answer below

Practice focus

Incident response, memory evidence, mitigation, deployment correlation, recurrence prevention, and communication.

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
An OutOfMemoryException restart restores capacity temporarily but can erase the most useful evidence. Recovery must reduce current user impact while preserving the memory curve, workload, deployment, instance, and crash artifacts needed to prevent recurrence.
I would first make sure the service is healthy after restart and users are not still affected. Then I would gather evidence: logs, memory metrics before the crash, traffic, recent deployments, endpoint mix, job activity, and any available dump or crash artifact. I would check whether the OOM happened on one instance or many. If a specific feature or job triggered it, I would limit or disable that path while investigating.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I would separate immediate recovery from diagnosis. Recovery might involve scaling, draining a bad instance, pausing a batch job, lowering concurrency, or rolling back a recent change. Diagnosis looks at the memory curve before the crash, allocation spikes, retained heap, payload sizes, and deployment diff. I would communicate the current mitigation and the evidence being collected. If no dump exists, I would set up safe dump capture or better memory telemetry before the next occurrence.

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

Stopping at restart because the service looks healthy again.
Deleting evidence during cleanup.
Rolling forward blindly without checking recent changes.
Ignoring whether one feature or tenant triggered the crash.

A production .NET service crashed with OutOfMemoryException and restarted. What would you do next?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Prerequisite

Tech stacks

Skill areas

Suggest an improvement