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
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 all Compose projects on the machine — their names, status, and whether they’re still running.

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

Real-World Example: CI Agent Gone Rogue#

I once walked into a client’s Jenkins server that was throwing disk full errors. A quick docker ps -s revealed that a dozen dangling build agents had ballooned up to 18GB each. They weren’t running. No one was watching. docker ps -a plus a --filter and -q combo gave me the container IDs, and in seconds, they were gone:

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

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

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.

Social Channels#

• 🎬 YouTube
• 🐦 X (Twitter)
• 🎨 Instagram
• 🐘 Mastodon
• 🧵 Threads
• 🎸 Facebook
• 🧊 Bluesky
• 🎥 TikTok
• 💻 LinkedIn
• 📣 daily.dev Squad
• ✈️ Telegram
• 🐈 GitHub

Community of IT Experts#

• 👾 Discord

Is this content AI-generated?

No. Every article on this blog is written by me personally, drawing on decades of hands-on IT experience and a genuine passion for technology.

I use AI tools exclusively to help polish grammar and ensure my technical guidance is as clear as possible. However, the core ideas, strategic insights, and step-by-step solutions are entirely my own, born from real-world work.

Because of this human-and-AI partnership, some detection tools might flag this content. You can be confident, though, that the expertise is authentic. My goal is to share road-tested knowledge you can trust.