The docker logs command: options and troubleshooting

docker logs retrieves a container's available stdout and stderr history through Docker's logging interface. It is useful for immediate troubleshooting, but it is not a multi-container search or independent long-term archive.

What you can retrieve depends on the configured driver, any dual-logging cache, rotation, and whether the container still exists.

Start with a container name or ID

docker logs myapp

To create a predictable disposable example:

docker run --name log-demo alpine:3.22 sh -c \
  'printf "example output\n"; printf "example error\n" >&2'
docker logs log-demo
# Remove only this disposable example after inspecting its output:
docker rm log-demo

The command returns retained output, not necessarily every byte since the container was first created. Older records may already have rotated away.

Combine the useful options

docker logs -f myapp
docker logs --tail 100 myapp
docker logs --since 30m myapp
docker logs --since 2026-08-25T14:00:00Z --until 2026-08-25T15:00:00Z myapp
docker logs -t myapp
docker logs --details myapp
docker logs --tail 50 -f -t myapp

-f follows new output; stop following with Ctrl+C. --tail starts from recent lines, and --since/--until bound the time window. -t adds Docker timestamps. --details adds configured log attributes, such as selected environment variables or labels—it is not an stdout/stderr marker switch.

A practical investigation starts with the failure window, identifies a relevant error, and then follows output while reproducing the issue. Expand the context only when needed.

Filter or separate output streams

# Search both streams for an error string.
docker logs myapp 2>&1 | grep -i error

# For a non-TTY container, capture stdout and stderr separately.
docker logs myapp 1>/tmp/out.log 2>/tmp/err.log

# Inspect a few containers sequentially.
for c in web-1 web-2 web-3; do
  docker logs --tail 20 "$c"
done

For non-TTY containers, the Docker CLI can preserve the stream distinction. Its own error messages can also enter stderr. A TTY container has a combined terminal stream, so shell redirection cannot reconstruct the original separation.

2>/dev/null discards stderr; it does not select stderr. To retain only the command's stderr, redirect stdout to /dev/null, while remembering the TTY and CLI-diagnostic limitations.

Understand drivers, caches, and retention

Drivers such as json-file, local, and journald support local reading. Remote logging drivers may also work with docker logs through Docker's dual-logging cache. If that cache is disabled or unavailable and the driver cannot read logs, inspect the configured backend.

Do not switch drivers solely because an old tutorial says all remote drivers return empty output. Inspect the container's real configuration first, and validate how the collector handles rotation.

A container restart retains the same container identity and can retain earlier logs within the driver's history. Removal and recreation produce a different container; remote history then depends on records already sent elsewhere. Docker does not have a docker logs --previous option. That syntax belongs to kubectl logs for a previous Kubernetes container instance.

Verify centralized collection

For application files mounted onto the host, configure DataKit file collection with the actual path, source, service, and Pipeline. For stdout/stderr, use a collection method supported by the runtime and driver; not every driver exposes the same local files.

Write a uniquely identified test log and compare local output with the centralized message, timestamp, and container identity. Check JSON field extraction, multiline assembly, missing events, and duplicates before setting alerts. Retention should reflect investigation needs independently of container deletion.

Frequently asked questions

What does “configured logging driver does not support reading” mean?

The current driver/cache combination cannot provide history through the read API. Check whether dual logging is supported and enabled, and inspect the remote backend when appropriate. Any driver change should fit the application's collection and retention design.

What time formats can I use?

Docker accepts documented timestamp forms, Unix timestamps, and relative durations such as 30m or 1h30m. Use a timestamp with Z or an explicit offset for cross-time-zone work. A timestamp without an offset is interpreted using the client's local timezone.

Why is a large log request slow?

Use --tail or a narrower time window and inspect rotation settings. For broader historical searches, use a properly configured indexed backend rather than repeatedly streaming an unbounded history.

Can I see logs from before a restart?

Yes, if the same container's logging history still retains them. There is no --previous flag. If the container was replaced or history rotated away, use an independently retained copy.

References

• Docker logs options
• Dual logging with remote drivers

Related reading

• Docker logging practices
• Docker Compose logs
• Linux logs (Chinese)
• Log management (Chinese)