docker logs -f: follow a container's logs live

Follow a container's logs

To watch a container's output live, pass -f (or --follow) with the container name or ID from docker ps. docker logs -f web prints the existing output and then streams new lines as they arrive. Ctrl+C stops the docker logs command in your terminal, not the container.

docker logs shows what the container's command writes to stdout and stderr, and --tail defaults to all. If a container has been running for days, dumping the whole history takes a while, so add --tail 100 or -n 100 to print only the last 100 lines before following.

docker ps --format '{{.Names}}  {{.Image}}  {{.Status}}'
docker logs -f web
docker logs -f --tail 100 web

Filter by time and add timestamps

When you only care about a recent failure or a specific window, filter with --since and --until. Both accept a timestamp like 2026-10-30T08:00:00Z or a relative time like 42m, and you can combine --since with --follow or --tail.

If your application doesn't print its own timestamps, pass -t (or --timestamps) to prefix every line with an RFC3339Nano timestamp.

docker logs --since 10m -t web
docker logs --since 2026-10-30T08:00:00Z --until 2026-10-30T09:00:00Z web
docker logs -f --since 5m web

Here is the full set of docker logs options:

Docker Compose logs

For multi-container projects, docker compose logs -f follows every service in the Compose file at once and interleaves their lines. To watch only some services, list their names at the end of the command.

• -n or --tail sets the number of lines per container (default all).
• --no-log-prefix drops the service name prefix, and --no-color turns off colors.
• --index picks one container when a service runs several replicas.
• --since, --until and -t work just like they do in docker logs.

docker compose logs -f --tail 50 api worker

When docker logs shows nothing

If docker logs prints nothing or fails with an error, the cause is usually the container's logging driver or how the process inside writes and buffers its output.

Check the logging driver

Docker's default logging driver is json-file. docker logs reads the local, json-file and journald drivers directly. With the none driver no logs are kept, and docker logs returns no output at all.

For remote drivers like splunk, Docker Engine turns on dual logging automatically: it keeps a local cache of up to 5 files of 20 MB each per container by default. If an admin disables that cache, docker logs fails with configured logging driver does not support reading. Check which driver a container uses with docker inspect:

docker inspect -f '{{.HostConfig.LogConfig.Type}}' web

Check where the app writes and whether Python buffers

A web server or database that writes to log files inside the container instead of stdout and stderr won't show up in docker logs. Point its logs at stdout, or read the files with docker exec.

For Python jobs, buffering is the usual culprit. Without a TTY, Python block-buffers stdout, so print() output only reaches docker logs in large chunks or when the container exits. Set PYTHONUNBUFFERED=1 or run python -u; the guide to unbuffered Python output covers the details.

FROM python:3.12-slim
ENV PYTHONUNBUFFERED=1
WORKDIR /app
COPY . .
CMD ["python", "train.py"]

Watch a long job without the Docker CLI

docker logs -f needs access to the Docker daemon, on the host itself or over SSH with docker -H ssh://user@host. For a long training run or batch job on a remote GPU box or a CI runner, a live link is easier to check from anywhere, as long as the container has outbound HTTPS. tqdml run streams the command's stdout and stderr to a page that keeps the last 500 lines, and still prints everything to docker logs.