A newly deployed .NET container never becomes healthy and keeps restarting. How would you diagnose it?

Diagnose container crash loops, image pulls, and OOM failures

Uses instance state, termination reasons, events, logs, configuration, probes, and resource evidence to distinguish common container startup failures.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I inspect deployment events and instance status for image-pull, scheduling, exit code, termination reason, and restart count. If the process ran, I read current and previous-instance logs because a restart may replace the visible stream. I compare image digest, command, configuration, secrets, ports, and architecture with the last healthy revision. OOMKilled points toward the memory limit and workload, while probe failures require checking both endpoint behavior and probe timing.

Full answer below

Practice focus

Image pull errors, entrypoints, startup exceptions, CrashLoopBackOff, probe failures, OOMKilled, events, logs, and rollback decisions.

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
I would first identify whether the image failed to start, the process exited, a probe triggered restarts, or the platform killed it. Those are different failure classes and leave different evidence.
I inspect deployment events and instance status for image-pull, scheduling, exit code, termination reason, and restart count. If the process ran, I read current and previous-instance logs because a restart may replace the visible stream. I compare image digest, command, configuration, secrets, ports, and architecture with the last healthy revision. OOMKilled points toward the memory limit and workload, while probe failures require checking both endpoint behavior and probe timing.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
For an image-pull failure I check the image reference, registry identity, network access, platform architecture, and whether the digest exists. For immediate process exit I run the exact image and command with production-like configuration in an isolated environment. For CrashLoopBackOff I do not treat the backoff as the root cause; I find the original exit or liveness failure. If user impact is active and the previous revision is compatible, I roll back while preserving evidence.

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

Reading only the latest log stream.
Calling CrashLoopBackOff the root cause.
Increasing probe delays without checking startup failure.
Editing the running container to make it work.

A newly deployed .NET container never becomes healthy and keeps restarting. How would you diagnose it?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Tech stacks

Skill areas

Suggest an improvement