Understand Docker run, start, and health starting states

docker run creates and starts a new container. docker start launches an existing created or stopped container. Running describes the container's process state, while starting may describe its health-check state. A container can be running and still show health: starting.

Follow the container lifecycle

No container -- create --> Created -- start --> Running
No container -- run -------------------------> Running
Running -- stop / process exit --> Exited
Exited -- start --> Running
Stopped container -- rm --> Removed

This is a simplified successful path. Creation or startup can fail, and containers can also be paused, restarting, or in other runtime states.

A new container receives a writable layer over its image and its configured mounts. Stopping retains that writable layer. Starting again launches the configured process anew; it does not resume the previous process's in-memory state. Mounted files may have changed while the container was stopped.

Inspect process and health state separately

docker inspect --format '{{.State.Status}}' web
docker inspect --format '{{json .State.Health}}' web

The health object exists when a health check is configured. starting means the check has not yet established a healthy or unhealthy result under its configured timing. One successful probe can mark the container healthy; the retry threshold concerns consecutive failures, not a required number of successes.

A running container may be unhealthy because its process is alive but cannot serve requests. Conversely, a container without a health check is not proven ready merely because docker ps reports it running. Health checks do not automatically restart unhealthy standalone Docker containers.

Use the correct command

docker run -d --name web nginx:stable
docker stop web
docker start web
docker restart web
# Stop before removing this example container:
docker stop web
docker rm web

These commands create one container, then operate on that instance. restart stops and starts it; it does not replace the image with a newly pulled tag. rm deletes the writable layer, so preserve needed data first.

docker create is useful when you want to configure an instance without starting its process yet. You can find it with docker ps -a and start it later.

Know which configuration requires replacement

docker start cannot add -p port mappings or inject a new creation environment. For those changes, recreate the service from its complete deployment definition. Not every container setting is immutable: supported resource or restart-policy settings can be updated, and networks have connect/disconnect operations. Check the specific setting rather than assuming all changes require deletion.

A replacement may need preserved writable-layer files, consistent volume data, credentials, and downtime planning. Sharing a named volume does not make recreation universally lossless, and an old container sharing that volume is not an independent data rollback.

docker compose up -d reconciles a service definition and can create, start, or recreate containers as needed. docker compose restart keeps existing container configuration; it does not apply newly edited environment variables. Source edits also need the appropriate rebuild or mount workflow.

Read status as evidence, not a guarantee

If startup is unexpectedly brief, inspect exit code, error details, logs, and any configured health output. A process that exits with zero may have completed its task correctly while failing the operator's expectation of a long-running service. Keep application readiness and the intended service behavior separate from the lifecycle command that was issued.

See Docker run, Docker start, and Docker health checks.