Essential Commands for Listing Docker Containers

Why Listing Containers Actually Matters#

Here’s the deal: containers are cheap, disposable, and everywhere. That’s the whole point. But when you’ve got 47 of them doing who-knows-what at 3AM during an incident, you better be able to see exactly what’s up, fast.

Here’s what container listings tell you (if you know how to read them):

• What’s running: or more importantly, what’s not
• Which ports are exposed (and why Jenkins is talking to the wrong service)
• Which ones just crashed five times in a row
• Who deployed that random PostgreSQL container last week
• How much disk space your zombie containers are chewing up

You want operational clarity? It starts with docker ps.

Core Commands: No Fluff, Just Output#

Let’s walk through the container listing commands that matter: the ones I actually use when things break.

1
docker ps

1
docker ps -a

1
docker ps -n 5

1
docker ps -q

1
docker stop $(docker ps -q)

1
docker ps -s

1
docker ps -a -s

1
CONTAINER ID   IMAGE     SIZE      ...
2
1a2b3c4d5e6f   redis     30MB (virtual 150MB)

1
docker ps --format "{{.ID}} {{.Image}} {{.Status}}"

1
docker ps --filter "status=exited"
2
docker ps --filter "health=unhealthy"
3
docker ps --filter "ancestor=nginx"

Docker Compose? Same Game, Different Commands#

If you’re living in docker-compose land (you rebel), the commands shift a bit:

1
docker compose ps

Lists containers in the current Compose project. Basically docker ps, but scoped to the docker-compose.yml in your cwd.

1
docker compose ls

Shows the Compose projects that are running on the machine, with their status and config files. Add -a to include stopped projects:

1
docker compose ls -a

Great when your team has 12 different Compose stacks lying around like forgotten pizza boxes.

Cleaning Up Exited Containers#

Exited containers are invisible to plain docker ps and still take disk. List their IDs with a status filter and hand them to docker rm:

1
docker rm $(docker ps -a -q --filter "status=exited")

docker container prune does the same for every stopped container and asks before it deletes.

Moral of the story: Knowing how to see containers is the first step to controlling them.

Corrected on 2026-10-07: docker ps -s and docker compose ls include stopped containers and projects only with -a, checked on Docker Engine 29.7.2 and Compose 5.5.1. An example that relied on the earlier wording was removed.

Takeaway: Don’t Just Run Containers: Own Them#

Listing containers isn’t a junior-level checkbox. It’s foundational. If you can’t tell what’s running, what’s dead, and what’s unhealthy in under 30 seconds, you’re one stray docker run away from production chaos.

So burn these into your muscle memory. Pipe them into your scripts. Alias the long ones. Teach them to your juniors.

And next time you SSH into a box and run docker ps, do it with confidence. You’re not just checking containers. You’re asserting control.