How to Check Docker Logs · ScreenshotNeo

To check a container’s output, run docker logs CONTAINER. Add -f to stream new output, --tail 100 to limit the initial history, and --since 30m to restrict it to a recent time window. For a Compose service use docker compose logs; for Docker’s own daemon use the operating system’s daemon logs instead.

Docker logs expose what a containerized process writes to stdout and stderr. They are different from Docker daemon logs, which help diagnose the runtime itself. The right command depends on whether you are inspecting a single container, a Compose service, a Swarm service, or the daemon.

1. Check logs for a single container

Start by listing containers so you have the correct name or ID:

Choose the log command based on whether you need a container, Compose service, Swarm service, or Docker daemon.

docker ps
# Include stopped containers too
docker ps -a

Then fetch the available output:

docker logs my-app

docker container logs is the expanded form of the same command:

docker container logs my-app

By default, Docker returns all available logs for that container and exits. It does not continuously refresh unless you request follow mode. The output includes the container’s stdout and stderr streams, which many applications use for their normal logs and errors.

Useful options at a glance

Option	Purpose	Example
`-f`, `--follow`	Keep streaming new output.	`docker logs -f my-app`
`--tail N`	Show only the last N lines initially.	`docker logs --tail 100 my-app`
`-t`, `--timestamps`	Prefix each line with its timestamp.	`docker logs -t my-app`
`--since TIME`	Show entries after a time or duration.	`docker logs --since 30m my-app`
`--until TIME`	Show entries before a time.	`docker logs --until 2026-09-29T10:00:00Z my-app`
`--details`	Include extra attributes configured through logging options.	`docker logs --details my-app`

Combine options to keep output focused while watching a live issue:

docker logs --follow --tail 100 --timestamps my-app

This prints the last 100 lines and then continues streaming. Press Ctrl+C to stop following; this stops the client command, not the container.

2. Filter logs by time

--since and --until accept Go duration strings, Unix timestamps, and RFC3339 timestamps. Durations are convenient for quick checks:

# Logs from the last 30 minutes
docker logs --since 30m my-app

# Logs from the last 3 hours
docker logs --since 3h my-app

# A specific interval in UTC
docker logs --since '2026-09-29T09:00:00Z' \
  --until '2026-09-29T10:00:00Z' my-app

Other valid duration examples include 1m30s. Use quotes around timestamps and compound values so the shell passes each as one argument. An explicit Z means UTC; an explicit offset such as -04:00 identifies another timezone. If a timestamp has no zone, Docker interprets it using the Docker client’s local timezone, which can make incident windows confusing when your laptop, server, and logs use different zones.

Timestamp display is separate from time filtering. Use -t when you want timestamps on output lines. Docker formats them using RFC3339Nano. The --until option is available from Docker API 1.35.

3. Check Docker Compose logs

For a Compose application, use the service name from your Compose file. From the directory containing the Compose project:

# All services
docker compose logs

# One service
docker compose logs api

# Follow one service, showing the latest 100 lines
docker compose logs --follow --tail 100 api

You can name multiple services as well. If a service has multiple replicas, --index selects a particular instance where applicable. Compose also has presentation options such as --no-color and --no-log-prefix, useful when saving output to a file or processing it in another tool:

docker compose logs --no-color --no-log-prefix api > api.log

Check docker compose logs --help for the options supported by the Compose version installed on your machine. Compose command options can differ from the single-container command, so do not assume every flag is accepted in every position.

4. Check Docker Swarm service or task logs

Run docker service logs on a Swarm manager node. A service target collects output from its tasks; a task target narrows the view to that task:

# Logs for a service
docker service logs --follow --tail 100 my_stack_api

# Find task IDs and inspect one task
docker service ps my_stack_api
docker service logs TASK_ID

This command is only functional for services started with the json-file or journald logging driver. If the service uses another driver, query that logging destination instead. A task may have been rescheduled, so inspect the service’s task list when the output does not correspond to the instance you expect.

5. Diagnose an empty or incomplete result

When a command returns no lines, work through these checks in order:

Confirm the target. Run docker ps -a and verify the container name or ID. A Compose service name and a container name are not always interchangeable.
Check whether the process writes to stdout or stderr. docker logs reads those streams. If the application writes only to a file inside the container, Docker’s log command will not show that file.
Inspect the logging driver. The driver may be none, which provides no output through docker logs, or a remote destination that you need to inspect separately.
Check the time filter. Remove --since and --until temporarily, or make the range wider. Confirm the timezone in any absolute timestamp.
For remote logging, inspect daemon logs and the remote destination. Docker’s dual logging cache can make some remote-driver output available locally, but a network issue can prevent a cache write. Failed cache writes are logged by the daemon and are not retried; the default cache is a ring buffer and may lose older entries.

To see the daemon’s default driver and a container’s configured driver:

docker info --format '{{.LoggingDriver}}'
docker inspect -f '{{.HostConfig.LogConfig.Type}}' my-app

The daemon default is json-file, but it can be changed globally or per container. A container keeps the configuration it was created with. Changing the daemon default does not update existing containers; recreate them to apply the new default.

6. Container logs versus Docker daemon logs

Use docker logs for an application’s container output. Use daemon logs when Docker Engine or Docker Desktop itself is failing—for example, if the daemon cannot start, cannot create a container, or reports a logging-driver error.

Environment	Daemon log location or command
Linux with systemd	`journalctl -xu docker.service`
Some Linux distributions	`/var/log/syslog` or `/var/log/messages`
Docker Desktop on macOS	`~/Library/Containers/com.docker.docker/Data/log/vm/init.log`
Docker Desktop on Windows with WSL2	`%LOCALAPPDATA%\Docker\log\vm\init.log`
Windows containers	Windows Event Log

Docker Desktop’s init.log includes a component field that can help distinguish services such as dockerd and containerd. Desktop paths and Linux log destinations depend on the platform configuration; if a documented path is absent, consult the logs available in that installation and check the daemon’s own diagnostic output.

7. Configure retention and avoid filling the disk

The json-file driver is Docker’s default, but its files can grow until they consume available disk space unless rotation is configured. Docker recommends configuring rotation for json-file or using the local driver for common non-Kubernetes use. The local driver rotates by default and stores logs in a format optimized for Docker’s performance and disk use.

Log driver and rotation settings determine how much history remains available on the host.

The local driver’s documented defaults retain 100 MB of messages per container: five files, each with a maximum size of 20 MB. Rotated files are compressed automatically. The relevant options include max-size, max-file, and compress; their defaults are 20m, 5, and enabled.

To make the local driver the daemon default, set the daemon configuration and restart Docker. For example, a Linux /etc/docker/daemon.json could contain:

{
  "log-driver": "local",
  "log-opts": {
    "max-size": "20m",
    "max-file": "5",
    "compress": "true"
  }
}

Log option values in daemon.json must be strings, including values that look like numbers or booleans. Docker Desktop users configure daemon settings in the Docker Engine settings interface. After changing a daemon default, restart Docker and recreate containers that should use it. Check the daemon configuration before applying changes on a production host, since the selected driver affects retention and where logs can be read.

Docker’s local-driver files are designed for exclusive Docker-daemon access. Avoid reading or modifying those files directly from outside Docker; use Docker’s log command and supported logging integrations.

8. Troubleshooting common errors

Symptom	Likely cause	What to do
`No such container`	Wrong name/ID, or the container was removed.	Run `docker ps -a`; for Compose, use `docker compose ps` and the service log command.
Command returns nothing	Wrong target, no stdout/stderr output, `none` driver, or an overly narrow time window.	Verify the target and driver; retry without time filters; inspect app files or remote destination if applicable.
Logs stop or omit older entries	Rotation, retention limits, or a remote cache ring buffer.	Check driver options and the remote logging system. Older entries may already have been rotated or evicted.
`invalid value` for `--tail`	The value is negative or not an integer.	Pass a non-negative integer such as `--tail 100`. An invalid value is treated as `all` by the documented command behavior.
Unexpected timestamps	Timestamp omitted a zone, so the client’s local timezone was used.	Use `Z` for UTC or include an offset; add `-t` to show line timestamps.
Swarm service logs unavailable	Not on a manager, or service uses an unsupported driver.	Run on a manager and confirm the service uses `json-file` or `journald`.
Disk usage grows despite log checks	`json-file` rotation is not configured.	Set rotation options or use `local`; restart Docker and recreate containers to adopt daemon defaults.
Docker itself fails but container logs offer no clue	The issue is in the daemon/runtime rather than the app process.	Inspect the platform’s daemon logs and look for component-specific errors.

9. Performance, reliability, and cost considerations

For a quick diagnosis, keep retrieval bounded with --tail and a time filter. Fetching all retained history can produce a large terminal dump and take longer to inspect. Follow mode is useful for reproducing a problem, but it remains open and prints every new line, so terminate it when finished or narrow it to the relevant service and initial tail.

Log reliability depends on both the application and the driver. Docker can only capture messages written to the container’s stdout and stderr. Rotation controls local disk use but also limits how much history remains locally. Remote drivers move storage elsewhere, while dual logging can provide a local cache with the documented limitations described above. For incidents, record the time range and timezone and check both the application destination and daemon diagnostics when the local output appears incomplete.

There is no separate charge for running docker logs; it is a Docker CLI operation. The operational cost is storage and retention: unlimited or unrotated files can consume disk, while tighter rotation trades history for bounded disk usage. Pick retention based on the amount of history needed for debugging and the storage available on the host.

10. Where ScreenshotNeo fits

Docker logs answer what a container process printed. If the issue is instead how a web page renders, a screenshot can make the visual state easier to inspect or attach to a report. ScreenshotNeo is a website screenshot API and MCP server from Yorker Media; it does not replace Docker log collection.

Or skip the browser setup

When the task is capturing a page rather than diagnosing container output, ScreenshotNeo takes a screenshot with one GET request. See the API documentation for options.

curl -G "https://api.screenshotneo.com/v1/shot" \
  -d access_key=YOUR_API_KEY \
  --data-urlencode url=https://stripe.com \
  -o shot.webp

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({
  access_key: 'YOUR_API_KEY',
  url: 'https://stripe.com'
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

ScreenshotNeo accepts cookie and consent banners and removes more than 60 known consent platforms, newsletter popups, and chat widgets before capture; each cleanup step can be disabled. Bot checks, blank pages, timeouts, failed loads, and cache hits are not billed, and response headers identify the page verdict and billing status. Its MCP server gives AI agents tools named take_screenshot, get_page_info, and capture_pdf. The free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000. Create a free account for 1,000 screenshots a month, no card required.

FAQ

Can I see logs from a container that has stopped?

Usually, if the container still exists and its logging configuration retained output. Use docker ps -a to find stopped containers. If it was removed or its logs rotated away, Docker may no longer have that history.

Does `docker logs` show files written inside the container?

No. It shows the container process’s stdout and stderr streams. Read application files through the application’s configured logging destination or another appropriate access method.

Why do I see timestamps without using `-t`?

Applications may print their own timestamps as part of each message. Docker’s -t option adds Docker timestamps to output lines.

Can I use these commands with a remote Docker context?

The CLI targets the Docker context currently selected. Check docker context show if the results appear to come from a different host, and remember that timestamp interpretation uses the client’s local timezone when no zone is specified.