Lesson 30 of 30

Debugging Running Containers

Q: I'm going to describe a container that keeps restarting in production. Walk me through exactly how you'd debug it, step by step.

A strong answer covers: Start with docker logs to see the actual crash output, rather than guessing — a restart loop is almost always an immediate crash; Use docker inspect for exit code and metadata (env vars, mounts, network config) once a hypothesis narrows; Reach for docker exec only on a still-running container, and know it doesn't apply to one that's already exited; Connect the failure to concepts from earlier in this track as needed — networking/service names, readiness vs depends_on, secrets/config injection, or resource limits (OOMKilled).

A container that's crashing, hanging, or unreachable is a diagnostic puzzle with a small, specific toolkit — and knowing which tool answers which question is what separates a five-minute fix from an afternoon of guessing.

14 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 3

A container shows status "Restarting (1) 4 seconds ago" in `docker ps -a`. What's the correct first diagnostic command, and why?

docker logs — a restart loop is almost always an immediate crash, and the logs show exactly what the last attempt printed before exitingdocker exec -it — get a shell inside the container to poke around before checking anything elsedocker stats — check whether the container is using too much CPU or memory

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on Debugging Running Containers

What interviewers actually ask about this, and what a strong answer has to cover.

I'm going to describe a container that keeps restarting in production. Walk me through exactly how you'd debug it, step by step.

A strong answer covers

Start with docker logs to see the actual crash output, rather than guessing — a restart loop is almost always an immediate crash
Use docker inspect for exit code and metadata (env vars, mounts, network config) once a hypothesis narrows
Reach for docker exec only on a still-running container, and know it doesn't apply to one that's already exited
Connect the failure to concepts from earlier in this track as needed — networking/service names, readiness vs depends_on, secrets/config injection, or resource limits (OOMKilled)

Likely follow-ups

docker ps shows the container as 'Up'. Does that tell you the application inside is actually healthy? What would?
The container is dying with exit code 137. What does that specifically tell you, and is it necessarily a code bug?

Practice these with the AI interviewer →

The plain-language idea

"The container isn't working" is the container equivalent of "the page is broken" — true, and not yet actionable. A real debugging pass reaches for a small, specific set of tools, each answering a different question:

docker logs <container> — what did the process inside actually print? The first stop for almost anything, and often enough on its own.
docker exec -it <container> sh — get an interactive shell inside the running container's own filesystem and process namespace, to poke around live (check a config file actually made it in, test a network call from inside, confirm an env var is really set).
docker inspect <container> — the container's full metadata as JSON: its actual environment variables, mounted volumes, network settings, restart count, and exit code if it died.
docker stats — live CPU/memory usage per container, for "is this container being killed for using too much memory" questions.

See it in a real thing: a container that keeps restarting

docker ps -a                          # status shows "Restarting (1) 4 seconds ago"
docker logs myapp                     # see the actual crash: "Error: connect ECONNREFUSED db:5432"
docker inspect myapp --format '{{.State.ExitCode}}'   # confirm it's exiting, not just slow to start

The logs immediately narrow this from "broken" to a specific, checkable hypothesis: the app can't reach db on port 5432. From there, the rest of this track supplies the actual diagnostic questions — is db a real service name on the same Compose network (the networking lesson)? Did depends_on let this container start before Postgres was actually ready (the same lesson's readiness gap)? Is the database container even running (docker ps)?

What people usually miss

Watch out

A container can be "running" and still be useless. docker ps showing Up 2 minutes only means the main process hasn't exited — it says nothing about whether that process is actually healthy. A HEALTHCHECK instruction in the Dockerfile (or a healthcheck defined in Compose/an orchestrator) is what turns "running" into a real, checkable "ready" signal — connecting directly back to the orchestration lesson's point that self-healing depends entirely on having a health check to detect against.
docker exec only works on a container that's still running. A container that crashed and exited needs a different approach — docker logs on the stopped container (logs persist after exit) or, for a deeper look, docker run a debug shell from the same image to reproduce the environment without the crashing command.
Resource limits cause a specific, recognizable failure mode. A container killed for exceeding its memory limit shows exit code 137 and an OOMKilled status in docker inspect — easy to misdiagnose as an application bug when it's actually a limit set too low for what the app legitimately needs.
docker logs --since and --tail narrow output to a relevant window instead of scrolling a container's entire history — a small, easy-to-forget detail that matters a lot on a long-running production container with days of accumulated logs.

Why this matters in interviews

A take-home or live debugging round that hands over a broken container setup is testing this whole track's synthesis at once, the same way the UX Fundamentals track's closing lesson tested a full audit checklist — not whether you remember one command, but whether you can narrow "it's broken" to a specific, verified cause using the right tool for the right question, then reason about why using what earlier lessons in this track already covered (layer caching, networking, secrets, orchestration).