How to Kill All Docker Containers

You have a dozen containers running and you want them all gone right now. The command you're looking for is a single line, but docker killCopy and docker stopCopy are not the same operation, and picking the wrong one can leave you with corrupted data or containers that immediately respawn.

This article gives you the one-liner, explains when to reach for killCopy versus stopCopy, and covers the two traps that make "kill everything" fail silently: restart policies and signal forwarding.

The command

docker killCopy takes one or more container IDs. To feed it every running container, wrap docker ps -qCopy in command substitution:

1
docker kill $(docker ps -q)

Docker sends SIGKILLCopy to the main process in each container and echoes back the ID of every one it killed:

123
3f2a9c1b4e7d
a1b2c3d4e5f6
c7d8e9f0a1b2

docker ps -qCopy prints the ID of each running container and nothing else, so the shell expands the whole thing into docker kill <id1> <id2> <id3>Copy. The containers stop immediately, with no grace period.

The long-form syntax does exactly the same thing, since docker killCopy is an alias for docker container killCopy and docker psCopy is an alias for docker container lsCopy:

1
docker container kill $(docker container ls -q)

If nothing is running, docker ps -qCopy returns an empty string and you'll get an error like this:

1
"docker kill" requires at least 1 argument.

That's harmless when you're typing at a prompt, but it breaks scripts and CI steps. Pipe through xargs -rCopy instead, which skips the command entirely when there's no input:

1
docker ps -q | xargs -r docker kill

On macOS the BSD version of xargsCopy doesn't support -rCopy, so guard the call with a conditional:

1234
containers=$(docker ps -q)
if [ -n "$containers" ]; then
  docker kill $containers
fi

You don't strictly need -rCopy on macOS in the first place: BSD xargsCopy already declines to run the command when its input is empty, which is exactly the behavior -rCopy buys you on Linux. So docker ps -q | xargs docker killCopy is safe on a Mac on its own. The reason to reach for the conditional is portability. The bare pipe errors out on Linux (GNU xargsCopy runs docker killCopy once with no arguments), and the -rCopy pipe errors out on macOS (BSD xargsCopy rejects the flag). The conditional does the right thing on both.

Should you use kill or stop?

docker killCopy sends SIGKILLCopy, which the kernel delivers to the process without giving it any chance to react. The process cannot catch it, flush buffers, or close file handles. It just dies. That's the right behavior when a container is wedged and won't respond, but it's the wrong default for anything holding open state.

docker stopCopy is the graceful version. It sends SIGTERMCopy, waits ten seconds by default for the process to shut down on its own, and only then sends SIGKILLCopy as a fallback:

1
docker stop $(docker ps -q)

The gap between the two is where data lives. A database mid-transaction, or an application still flushing logs, needs SIGTERMCopy and a moment to clean up. Kill it outright and you risk half-written files or a database that has to replay its journal on next boot, assuming it can. If ten seconds isn't enough for a heavy service to drain, extend the timeout with docker stop -t 30 $(docker ps -q)Copy. For the full treatment of graceful shutdown, custom signals, and timeout tuning, see how to stop a Docker container.

The short version: use docker killCopy when you want an immediate hard stop and you know the workloads can take it, and docker stopCopy for anything with persistent state.

Killing and removing in one step

Stopping or killing a container doesn't delete it. It sits in an ExitedCopy state, still consuming disk for its writable layer and still holding its name, which blocks you from starting a new container with the same one.

To stop and remove everything, including already-stopped containers, use docker ps -aqCopy (the -aCopy includes stopped containers) with a forced remove:

1
docker rm -f $(docker ps -aq)

docker rm -fCopy sends SIGKILLCopy before removing, so this is the destructive, no-grace-period option. If you want a clean shutdown first, do it in two steps:

1
docker stop $(docker ps -aq) && docker rm $(docker ps -aq)

If there are no containers at all, the docker stopCopy half prints the same "requires at least 1 argument" error from earlier and exits non-zero, so the &&Copy short-circuits and docker rmCopy never runs. Interactively that's the outcome you want (nothing to stop, nothing to remove) with a line of noise on stderr. In a script it's a trap: under set -eCopy, or as a CI step, that non-zero exit fails the whole step even though nothing was wrong. Guard each half the same way as before if that matters:

12
docker ps -aq | xargs -r docker stop
docker ps -aq | xargs -r docker rm

For the complete cleanup picture, including bulk removal with docker container pruneCopy, filter-based deletion, and the orphaned-volume cleanup most guides skip, see how to remove a Docker container.

Common pitfalls

Containers that come back from the dead. If a container was started with --restart=alwaysCopy or --restart=unless-stoppedCopy, docker killCopy triggers exactly the condition the restart policy is watching for, and Docker relaunches it within seconds. You'll run your kill command, see the IDs scroll past, then find the same containers running again. docker killCopy doesn't clear the policy. Either remove the containers with docker rm -fCopy, or use docker stopCopy, which Docker treats as an intentional stop that suppresses the policy for the current daemon session. Restart policies have more sharp edges than that (the ten-second rule, alwaysCopy surviving a manual stop across a reboot); how to start Docker containers automatically after reboot covers them.

The signal that never arrives. This one is specific to how your image is built, and it's really a docker stopCopy problem you'll hit right before you reach for killCopy. If your ENTRYPOINTCopy or CMDCopy uses the shell form (CMD node server.jsCopy rather than CMD ["node", "server.js"]Copy), your process runs as a child of /bin/sh -cCopy, which becomes PID 1. The shell doesn't forward signals to its children, so your application never sees the SIGTERMCopy, burns the full timeout, and gets SIGKILLCopyed every time. Switch to the exec form (the JSON array syntax) so your process runs as PID 1, or add an init process with docker run --initCopy. It's the same shell-as-PID-1 trap that catches Compose commandCopy strings, which how to run multiple commands in Docker Compose digs into.

Compose containers fight back. If your containers are managed by Compose, killing them by ID leaves Compose's view of the world out of sync, and docker compose upCopy may recreate them. Stop them through Compose instead so it stays authoritative:

123
docker compose stop        # graceful stop, keeps containers
docker compose down        # stop and remove containers and networks
docker compose kill        # immediate SIGKILL

Final thoughts

You now have the one-liner, the reason to prefer docker stopCopy for anything holding state, and the two traps that make a mass kill misfire: restart policies that respawn containers, and shell-form entrypoints that swallow the shutdown signal.

Reaching for a mass kill is usually a sign you've lost track of what's running and why. In development that's fine. In anything shared or production-adjacent, the better position is knowing which containers keep restarting and what they were handling when they stopped, before you reach for the kill switch. Once you've outgrown raw dockerCopy commands and moved to an orchestrator, Kubernetes monitoring is where that same visibility lives.

Dash0's infrastructure monitoring is OpenTelemetry-native and tracks container resource usage and restart behavior alongside real-time logs and distributed traces, so you can see what a container was handling before it went down rather than guessing after the fact. If it's specifically the logs you're chasing, Mastering Docker Logs covers getting them off the host before a container is gone. Start a free trial to monitor your containers, hosts, and clusters in one view. No credit card required.