Command-Line Techniques for Listing All Docker Containers

Experienced DevOps and SRE teams routinely need to audit Docker hosts: not only for currently running workloads, but for any container that has traversed the system’s lifecycle. Relying solely on the default output of docker ps exposes a blind spot—exited, paused, or failed containers accumulate, inflate disk usage, and obscure the system's real state.

The Standard View—Active Containers Only

On any Docker v20.10.x+ environment, running:

docker ps

delivers a live snapshot like:

CONTAINER ID   IMAGE          COMMAND                  CREATED        STATUS       PORTS                  NAMES
fc34ad12c893   postgres:15    "docker-entrypoint.s…"   3 hours ago    Up 3 hours   5432/tcp               db01
8ab9cd73f211   nginx:1.25     "nginx -g 'daemon of…"   20 minutes ago Up 19 min    0.0.0.0:8000->80/tcp   web-nginx

Only containers whose current state is "running" appear in this output. Systems with extensive CI/CD pipelines can easily accumulate dozens of orphaned, stopped containers unless managed explicitly.

Surface Everything: docker ps -a

To see every container—including those with non-zero exit codes, paused, or created but never started—append -a:

docker ps -a

Partial sample output:

CONTAINER ID   IMAGE        COMMAND                  CREATED        STATUS                        PORTS                  NAMES
8ab9cd73f211   nginx:1.25   "nginx -g 'daemon of…"   21 minutes ago Up 20 minutes                0.0.0.0:8000->80/tcp   web-nginx
b677f0b502cb   alpine:3.18  "sleep 100"              34 minutes ago Exited (0) 12 minutes ago                           temp-job
44e1c7081a6a   redis:7.0    "docker-entrypoint.s…"   2 hours ago    Exited (137) 90 minutes ago                          redis-build

Note
Disk space on /var/lib/docker/containers can balloon if historical containers are ignored. Regular audits via docker ps -a limit surprises during upgrades or disk monitoring.

Precision View: Filter by Container State

Working on a build node and only interested in containers that failed or finished? Use --filter (shorthand: -f):

docker ps -a --filter "status=exited"

Useful filter values:

• created
• running
• paused
• exited
• dead
• removing
• restarting

Example (only exited containers):

CONTAINER ID   IMAGE        COMMAND       CREATED           STATUS                        NAMES
b677f0b502cb   alpine:3.18  "sleep 100"   35 minutes ago    Exited (0) 13 minutes ago    temp-job
44e1c7081a6a   redis:7.0    "docker-e…"   2 hours ago       Exited (137) 92 minutes ago  redis-build

Gotcha:
Some third-party orchestration tools (e.g., older versions of Docker Compose prior to v2) may leave behind containers in an odd "removing" or "dead" state—not shown in docker ps without filtering.

Automation: Quiet and Formatted Output

Automation benefits from a clean list of container IDs or custom fields. Use -q for IDs only:

docker ps -a -q

Output:

8ab9cd73f211
b677f0b502cb
44e1c7081a6a

For tailored output (Go templating), for example, ID and NAME columns, try:

docker ps -a --format '{{.ID}}\t{{.Names}}'

Result:

8ab9cd73f211	web-nginx
b677f0b502cb	temp-job
44e1c7081a6a	redis-build

Side note
Malformed templates—missing field names, for example—throw parsing errors and break large cleanup loops. Always test with a small list.

Cleanup: Removing Orphaned and Exited Containers

Long-running hosts develop clutter. To clear all exited containers (safe for ephemeral CI/CD workers but dangerous on prod if retention is needed):

docker rm $(docker ps -a -q -f status=exited)

Practical tip
docker system prune -f will delete all stopped containers, unused images, and networks—not always desirable. Prefer targeted docker rm pipelines during scheduled maintenance, with logs from docker inspect archived elsewhere.

Summary Table

Non-Obvious Tip

When analyzing historical issues or debugging odd container failures, add --no-trunc to prevent line-wrapping of full IDs and commands:

docker ps -a --no-trunc

You’ll spot odd entrypoint overrides or ultra-long IDs that get cut in default mode.

Routine container listing isn’t glamorous, but neglect causes hidden state and operational surprises. These commands form the foundation for robust Docker host management—integrate them into health checks, CI/CD runners, and provisioning playbooks. For complex scenarios, consider layering on docker inspect or even direct API queries; sometimes the CLI's surface view isn’t enough.

Known issue: Some Docker Desktop environments on macOS silently prune stopped containers when disk space shrinks below a threshold; don’t rely on historical listings being complete on those hosts.