Pause and Resume Docker Containers with docker pause

docker pause freezes every process inside a container without stopping it, so you can hold a service still for a moment without losing its state. You will pause one or more running containers, confirm they are actually paused, then bring them back with the matching docker unpause. Allow about ten minutes, plus time to check the application tolerates a short interruption.

This guide uses Docker CE CLI 29.8.1 on Linux. You need a reachable Docker daemon and permission to access its Unix socket, either through membership of the docker group or sudo. Use whatever privilege level already works for your normal Docker commands.

1. Confirm the command and choose the target

docker pause is an alias for docker container pause. Its only argument is one or more container names or IDs:

$ docker pause --help
Usage:  docker pause CONTAINER [CONTAINER...]

Pause all processes within one or more containers

Aliases:
  docker container pause, docker pause

List running containers before you touch anything. A short ID is easy to misread in a busy terminal, so check the name carefully:

$ docker ps --format 'table {{.Names}}\t{{.Status}}\t{{.Image}}'
NAMES              STATUS                 IMAGE
web-production     Up 2 hours             example/web:2026.09
worker-production  Up 2 hours             example/worker:2026.09

2. Know what pause actually does

• It is reversible, but still disruptive. On Linux, Docker uses the freezer cgroup to suspend the container's processes. Nothing inside keeps handling work while paused.
• Connections do not wait politely. Existing network connections may stall or time out, and an orchestrator or monitoring system can report the service as unhealthy.
• Pause is not a shutdown. Use docker stop when the application needs its normal termination signal and a chance to release resources.
• Do not use it as a backup trick. Only pause a stateful service for a backup if the procedure specifically calls for that boundary and you have tested the recovery path.

3. Pause the selected container

Swap in the name you checked in step 1:

$ docker pause web-production
web-production

A successful command prints the affected container name. It does not print the processes inside it and does not create a snapshot; it only changes runtime state. Keep the terminal output and exit status as part of your maintenance record.

For more than one container, list each reviewed name explicitly:

$ docker pause web-production worker-production
web-production
worker-production

4. Verify the paused state

Filter docker ps for paused containers:

$ docker ps --filter status=paused --format 'table {{.Names}}\t{{.Status}}'
NAMES            STATUS
web-production   Up 2 hours (Paused)

For an exact check of one container, ask Docker directly for its state:

$ docker inspect --format '{{.Name}}: {{.State.Status}}' web-production
/web-production: paused

5. Resume the container

When the maintenance work is done, bring the same container back with docker unpause:

$ docker unpause web-production
web-production
$ docker inspect --format '{{.Name}}: {{.State.Status}}' web-production
/web-production: running

This resumes the suspended processes. It does not restart the container, replay missed work, or guarantee clients reconnect on their own, so check the service's health endpoint, logs or queue metrics afterwards.

If you paused several containers, resume the same reviewed set:

$ docker unpause web-production worker-production
web-production
worker-production

Common traps

• Pause is not stop. Pause suspends processes. Stop asks the application to terminate, then may force it to exit after a timeout.
• Do not run interactive commands inside a paused container. Unpause it first, or use a separate diagnostic container if the incident calls for one.
• Do not trust a name from an old deployment. Re-run docker ps immediately before the change, especially after a redeploy.
• Do not leave a maintenance pause unattended. Record the start time, owner and intended resume point, then verify the state after resuming.
• Do not reach for sudo out of habit. Use it only when the Docker socket policy requires it, and weigh up the security implications of granting daemon access.