`docker compose ps` Is the Command You Should Run Before Pretending Your Containers Are Up Just Because `up` Returned Cleanly

Why this command matters: docker compose up can look successful while one of the services you care about has already exited, restarted, or never became healthy.

One of the most common local-stack debugging mistakes is assuming that because Compose printed a lot of startup output, the stack is fine. That assumption wastes time. Databases can die on bad config. API containers can crash on migration failures. Workers can exit because of missing environment variables. The stack can be half-alive while the terminal session still feels reassuringly busy.

That is why docker compose ps should be one of your first sanity checks.

Start with the actual service state

docker compose ps

This gives you a compact table showing:

1. the service name
2. the container name
3. the current state
4. published ports

That already answers a more honest question than “did Compose run?” The better question is: which containers are still alive right now?

What to look for

If a container shows Exited, the startup problem is not hypothetical. It already happened.

If a service you expected to expose a port is missing a published port mapping, your browser and API client will fail no matter how confident the rest of the stack looks.

If multiple services are running but the one dependency you need is not, that changes the next debug step immediately.

For example:

docker compose ps
docker compose logs api
docker compose logs db

That sequence is a lot better than rerunning docker compose up ten times and hoping the outcome turns philosophical.

Why this is especially useful in multi-service stacks

Compose problems are often partial. Your frontend may run. Your database may run. Your worker may die. Your queue may still be waiting on a configuration you forgot to load.

docker compose ps helps you stop thinking of the stack as a single yes-or-no object. Real stacks fail in fragments.

That matters because the fix depends on which fragment failed:

1. api exited means check app startup and env
2. db exited means check database config and persisted state
3. worker exited means check queue config, imports, and runtime dependencies
4. missing ports means check the Compose file, not the app route handlers

A practical workflow

When the stack feels wrong:

docker compose ps
docker compose logs --tail=100 api
docker compose logs --tail=100 db
docker compose exec api env | sort

Now you are not debugging “Docker.” You are debugging a specific service failure with real context.

Common mistake

The biggest mistake is treating container startup as binary success. A container may start and crash instantly. A healthcheck may fail after initial startup. A service may stay up but bind to the wrong port or fail dependency checks.

docker compose ps does not explain everything, but it tells you where to look next.

Final recommendation

Before you tell yourself the stack is up, ask Compose to prove it. docker compose ps is still one of the fastest ways to separate “containers exist” from “the services I actually need are running.”

Sources

• Docker Compose CLI reference