Essential Commands for Listing Docker Containers

If you don’t know what’s running in your Docker environment, you’re not running it — it’s running you.
Whether you’re babysitting a dev laptop with three containers or wrangling a prod swarm that never sleeps, listing containers is the first move in any troubleshooting dance. And yet, too many engineers treat docker ps
like some dusty man page trick instead of what it is: a daily-use diagnostic scalpel.
Let’s fix that.
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.
List Running Containers
docker ps
This is the default. It shows only running containers — none of your sad, exited ghosts.
Fields you’ll see:
CONTAINER ID
IMAGE
COMMAND
CREATED
STATUS
PORTS
NAMES
If all you need is to check what’s up and listening on port 8080, this is your guy.
See All Containers (Even the Dead Ones)
docker ps -a
Want to know why that database backup failed overnight? This is where your exited containers live.
Useful for:
- Postmortems
- Audits
- Catching misfired
docker run
commands your CI forgot to clean up
Show the Last N Containers
docker ps -n 5
Shows the latest 5 containers, regardless of whether they’re running or not. Great when you’re trying to track down what just happened.
Just the IDs (For Scripting)
docker ps -q
Only container IDs. No fluff. Perfect for feeding into other commands:
docker stop $(docker ps -q)
Pro tip: pair with -a
if you want all container IDs, not just running ones.
Show Container Sizes
docker ps -s
Ever wonder why your CI agents are eating 20GB of disk? This command shows both the actual size and the virtual size of each container.
CONTAINER ID IMAGE SIZE ...1a2b3c4d5e6f redis 30MB (virtual 150MB)
Good for pruning. Better for avoiding the next disk outage.
Custom Output with --format
docker ps --format "{{.ID}} {{.Image}} {{.Status}}"
When you’re piping into tools or just hate staring at wide terminal tables, --format
gives you control.
Use this with:
--no-trunc
to avoid chopped-off IDs and commands- JSON outputs if you’re feeding this into monitoring scripts
Filter Like a Pro
docker ps --filter "status=exited"docker ps --filter "health=unhealthy"docker ps --filter "ancestor=nginx"
This is where docker ps
turns into grep on steroids. Use it to:
- Track misbehaving containers by health status
- Find all containers started from a specific image
- List containers tied to a specific label
Docker Compose? Same Game, Different Commands
If you’re living in docker-compose
land (you rebel), the commands shift a bit:
docker compose ps
Lists containers in the current Compose project. Basically docker ps
, but scoped to the docker-compose.yml
in your cwd.
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:
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)
- 🐘 Mastodon
- 🧵 Threads
- 🧊 Bluesky
- 🎥 TikTok
- 📣 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.