Docker logs: view output, find errors, and configure rotation

The docker logs command reads the output captured from an individual container. Start with a small number of recent lines, add a time window, and then follow new output if the failure is still happening. If logs are missing or disk usage keeps growing, check the application’s output and the container’s logging driver before changing anything.

This guide assumes Docker Engine is installed and you have authorized access to it. Commands use a container named api; replace that name with yours. Shell pipelines and file-export examples use a POSIX shell on Linux or macOS. For installation on a VM, see our guide to running Docker on Compute with Hivenet.

Find the right container and read recent logs

Check your Docker context first, especially if you switch between a laptop and a remote VM. Then list containers, including stopped ones, and read the last 100 lines:

docker context show
docker ps -a
docker logs --tail 100 --timestamps api

The context command identifies the selected context; also account for any environment variables or command flags that override the connection. Docker’s container list shows names and IDs. A stopped container can retain readable logs until it is removed, subject to the logging driver and retention.

Application logs usually contain a mixture of startup messages, requests, warnings, and errors. The absence of an error line does not establish that a request succeeded. Match the timestamp and request identifier to the incident you are investigating.

Follow output and narrow the time window

To display recent output and keep receiving new lines:

docker logs --follow --tail 50 api

Press Ctrl+C to stop following the output. That ends this log-viewing command; it does not stop the container. Use a time window when an unbounded stream would hide the relevant event:

docker logs --since 30m --timestamps api
docker logs --since "2026-10-29T09:00:00Z" --until "2026-10-29T09:10:00Z" api

The first command uses a relative interval. The second uses UTC timestamps, indicated by Z. Replace the example dates with your incident window. Docker accepts other supported timestamp forms, but an explicit timezone avoids confusion between your machine and the server. See the docker logs command reference for these options.

For a quick text search in a POSIX shell:

docker logs --since 30m api 2>&1 | grep -i -E 'error|timeout|exception'

2>&1 combines standard error with standard output before the search. Without it, error output can bypass the pipe. This is a text filter, not a reliable severity parser: it can miss structured events, hide stack-trace context, or match an ordinary message containing “error.” Return to the unfiltered time window before drawing a conclusion.

Read Docker Compose logs by service

From the directory containing the intended Compose file, use service names rather than guessing generated container names:

docker compose ps -a
docker compose logs --tail 100 --timestamps api
docker compose logs --follow --tail 50 api worker

The last command follows two services together. With no service argument, docker compose logs selects the project’s services. Its --tail limit applies to each container, so 100 lines does not mean 100 lines across the whole project. Keep the service prefixes when correlating an API failure with a worker failure. --no-color is useful for plain-text output. These behaviors are documented in the Compose logs reference.

Why docker logs shows no output

Docker normally captures the container process’s standard output and standard error. It does not automatically collect every application log file inside the container. An application that writes only to its own file may need an application-level logging change or a separate collector. Check the application’s configuration rather than creating guessed symlinks. Docker’s container logging overview explains this distinction.

Next, compare the daemon’s default with the actual container configuration:

docker info --format '{{.LoggingDriver}}'
docker inspect --format '{{json .HostConfig.LogConfig}}' api

The first command describes the default for new containers. The second describes this container, including its driver options. A driver of none means Docker is not retaining container logs. A default value alone cannot tell you how a container created last week is configured.

A remote logging driver does not always make docker logs unavailable. Docker can maintain a local cache through dual logging. If that cache is disabled and the driver cannot read logs locally, inspect the configured remote destination. Treat the cache as a limited recent view: remote write failures and other documented limitations can leave gaps. It is not a durable archive.

Save a bounded incident extract

Save only the window you need. On a POSIX shell, choose a new filename, then run:

umask 077
docker logs --since 30m --timestamps api > incident-api-20261029-0900.txt 2>&1

The restrictive umask limits permissions on a newly created file. It does not repair permissions on an existing file, and > overwrites an existing destination. Verify the filename first. The merged output may include Docker diagnostic messages as well as application output.

Review the extract before sharing it. Remove tokens, authorization headers, personal data, and signed URLs. Record the container, image version, incident timezone, and relevant deployment change alongside the extract. Those details make a small set of lines more useful than an unexplained log dump.

Configure log rotation before disk space runs out

Docker’s default json-file driver has no size limit unless configured. For ordinary standalone Docker use, Docker recommends the local driver, which rotates logs by default. See logging driver configuration. Check collector compatibility before switching drivers.

For one Compose service, merge this fragment into its existing definition. Keep the service’s image, environment, volumes, ports, and other settings:

services:
  api:
    logging:
      driver: local
      options:
        max-size: "10m"
        max-file: "3"

The Compose logging attribute sets the driver and options per service. This fragment is not a complete application deployment.

With the local logging driver, these settings rotate a file at 10 MB and retain up to three files; older files are removed as rotation proceeds. Rotated files are compressed by default. This is a size-based retention policy, not a guarantee of several days of history. A busy service can overwrite its recent history quickly, and the settings do not cap the application’s separate log files or total VM disk usage.

If a collector requires JSON log files, keep json-file and configure both options. For that driver, max-file takes effect only when max-size is set. Docker’s JSON file driver reference also warns against manipulating Docker-managed log files with external tools. Do not build a cleanup job around manually truncating them.

Apply changes through a planned container recreation

A logging change does not retrofit an existing container. Before recreating the service, save the incident evidence, confirm that persistent data is on the intended volumes, and plan for interruption. In the correct Compose project, validate the merged configuration and apply the changed service definition:

docker compose config --quiet
docker compose up -d --no-deps api
docker compose ps -a
docker compose logs --tail 50 --timestamps api

Compose up recreates containers when their configuration has changed; --no-deps avoids starting dependencies. A single-replica service can be interrupted. A restart alone is insufficient to adopt a different logging configuration.

Use the container ID shown by docker compose ps -a to verify the result:

docker inspect --format '{{json .HostConfig.LogConfig}}' CONTAINER_ID

Confirm the driver and options, then trigger a normal test request and check that its log entry appears. Also verify the application’s health through its usual endpoint. A readable log stream does not prove the service is healthy. Changes to the daemon-wide default require a separate planned Docker restart and still affect newly created containers rather than retroactively updating existing ones.

Container logs and Docker daemon logs are different

If Docker itself cannot start a container or connect to a logging driver, the relevant error may be in the daemon log. On a Linux host running Docker as a systemd service, start with:

journalctl -u docker.service --since "30 minutes ago" --no-pager

Journal access depends on your permissions. Docker Desktop and rootless setups have different locations or service arrangements; use Docker’s daemon log instructions for your installation. Do not assume a path under /var/lib/docker/containers exists on every Docker host or contains the logs you need.

Decide how much log history you need

Local rotation protects a limited amount of disk space. If you need logs after a container or VM is removed, send them to a separate logging destination with explicit retention, access controls, and alerts for collection failures. Decide which events justify long retention and which verbose debug messages should expire quickly.

On a VM you operate with Compute with Hivenet, include application logging and disk monitoring in your operating plan. Our VM or container guide helps distinguish the environments. This article’s commands assume access to the Docker daemon; they are not a promise that the same controls exist in a managed container service.