Trick to loop/autorefresh docker ps view like top/htop in bash
System Design practice on Codemia
Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.
Introduction
docker ps is a snapshot command, not an interactive monitor. If you want a live view that behaves more like top or htop, the usual approach is to rerun docker ps on a timer with watch or a small Bash loop and keep the output narrow enough to scan quickly.
The Fastest Option: watch
On most Linux systems, watch is the easiest tool for this job:
That reruns docker ps every two seconds. It is a good default when you are waiting for a container to start, restart, or disappear.
The default docker ps output is often wider than the terminal, so using --format makes the live view much cleaner:
This reduces noise and keeps the important columns stable while the screen refreshes.
Using A Bash Loop For More Control
If watch is missing or you want to customize the screen, a Bash loop gives you more control:
This behaves like a minimal dashboard. The clear call erases the previous frame, docker ps prints the current container state, and sleep 2 controls the refresh interval. Exit with Ctrl+C.
One advantage of a loop is that you can add your own context. A timestamp is often the first useful addition:
That makes it easier to match what you see on screen with logs, deploy steps, or health-check failures.
Filtering The Output
On a busy host, a full docker ps table becomes hard to read. Use filters and narrower columns to focus on a specific service:
If you are debugging crash loops, include exited containers as well:
That is important because containers that fail immediately may not stay in the running list long enough to notice.
Wrapping It In A Shell Function
If you do this often, a shell function saves time and keeps the quoting in one place:
Now you can run:
Or choose a different refresh interval:
You can add other flags, such as a name filter or -a, once you see what you use repeatedly.
When docker ps Is Not Enough
docker ps tells you which containers exist and whether Docker considers them up, restarting, or exited. It does not give live CPU and memory usage. If your real goal is resource monitoring, use docker stats:
That command is much closer to top semantics because it streams usage data continuously. A common workflow is to watch docker ps for state changes and switch to docker stats when you need to see whether a container is CPU-bound or memory-constrained.
Another useful variation is to pair a live docker ps view with logs in a second terminal:
That gives you a state view in one pane and the application output in another.
Quoting And Portability
Docker's --format option uses Go-template placeholders such as {{.Names}}. The shell also interprets quotes and special characters, so command quoting matters. A reliable pattern is:
- wrap the whole
watchcommand in double quotes - use single quotes inside the Docker format string
- keep the format short enough to fit the terminal
If the quoting is wrong, watch may run but Docker may receive a broken template. That usually shows up as missing columns or template parse errors.
Common Pitfalls
- Refreshing too quickly and creating a flickering screen that is harder to read than a static command.
- Forgetting that
docker psonly shows running containers unless you add-a. - Watching too many columns at once and making status changes easy to miss.
- Using
docker pswhen the real question is CPU or memory usage, which belongs todocker stats. - Misquoting the Go-template placeholders inside a
watchcommand.
Summary
- '
watch -n 2 docker psis the quickest way to get an auto-refreshing container view.' - A Bash loop is better when you want timestamps, custom layout, or extra logic.
- '
--formatkeeps the display compact and readable.' - '
docker ps -ahelps when containers exit too fast to observe.' - '
docker statsis the right tool when you want a live resource dashboard instead of state snapshots.'
Related reading
- Trying to start the kubernetes in Docker-Desktop but it's stuck
- UDP send and receive in kubernetes
- Unable to access my minikube cluster from the browser ❗ Because you are using a Docker driver on windows, the terminal needs to be open to run it.
- Unable to connect to mongoDB running in docker container
- Trigger Github Actions only when PR is merged
- Triggering Azure DevOps builds based on changes to sub folders
- Unable to get a shell into citadel container in kubernetes
- Unable to install Chromium inside a docker container on M1 macbook

System Design Fundamentals
Build a strong foundation in designing scalable, reliable distributed systems.
View the courseTrack what you have practised
A free account saves your progress, solutions and study plan across every problem on Codemia.
System Design practice on Codemia
Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.