Docker Logs Command Guide with Examples and Fluxtail

A deployment has just started failing, one container keeps restarting, and the incident channel needs evidence before anyone changes configuration. The fastest first check is usually the Docker logs command, but only when its scope is understood: it reads log output already available for a container, primarily its standard output and standard error. It doesn't create a durable central archive, reconstruct events from every host, or replace a log management system.

For on-call work, the useful sequence is straightforward. Identify the container, inspect existing output, narrow the result with time and line filters, add timestamps for correlation, then stream new entries when the failure is still active. If the investigation spans hosts, services, or retention periods, the team should move from local inspection to centralized collection.

Table of Contents

• Introduction to Docker Logs for Incident Triage
• How the Docker Logs Command Works
  • Batch retrieval versus streaming
  • What the logging driver changes
• Docker Logs Flags Reference With Practical Examples
  • 持續取得新輸出
  • 限制輸出行數
  • 加上時間戳記
  • 設定起始時間
  • 設定結束時間
  • 要求額外屬性
• Building Precise Time Windows for Debugging
  • Start with a bounded live view
  • Reconstruct a known incident window
  • Check the clock before interpreting results
• Working With Multiple Containers and Compose
  • Compose service workflows
  • Make handoffs reproducible
• Log Storage Rotation and Driver Limits
  • Rotation settings that affect retention
  • Why local logs aren't durable retention
• Forwarding Docker Logs to Fluxtail for Central Analysis
  • Use a collector rather than treating the CLI as a shipper
  • Route records into named streams
• Quick Reference for Docker Logs Command Options
  • Docker Logs Flags Quick Lookup
  • Local versus centralized use
• Conclusion and Next Steps With Fluxtail

Introduction to Docker Logs for Incident Triage

A container starts failing during an incident, but the image has no shell and the application is still running. From the host, begin with:

docker logs CONTAINER

The command returns output Docker has retained for the named container. The official Docker container logs documentation describes its purpose: viewing a container's logs, with behavior centered on messages written to stdout and stderr. If the process writes useful operational events elsewhere, those entries will not automatically appear here.

That makes docker logs a local triage tool. It works like a nearby incident notebook, showing what one container emitted on one host. You can inspect startup messages, dependency errors, request failures, and shutdown output without installing debugging utilities or opening a shell inside the image.

Practical rule: Use docker logs to answer “what did this container emit?” Use centralized logging to answer “what happened across services and hosts over the incident window?”

By default, the command returns output already available when it runs. Add --follow when the failure is active:

docker logs --follow CONTAINER

Docker prints the existing entries first, then continues displaying new stdout and stderr output. This provides immediate context followed by live updates. Stop the stream when you have captured the relevant evidence.

Local output also has limits. It may be affected by the container's logging configuration and available retention, so it is not a durable central archive. For evidence-grade timelines, record timestamps and time boundaries, preserve the exact commands used, and move to centralized Fluxtail streams when the investigation requires shared access, cross-service correlation, alerting, or retention beyond local container storage.

How the Docker Logs Command Works

During an incident, start by identifying the container before interpreting its output:

docker logs [OPTIONS] CONTAINER

CONTAINER accepts a name or ID. List running containers with:

docker ps

If the process has already stopped, include stopped containers:

docker ps -a

Then request the available output:

docker logs payments-api

This reads the log records Docker can access for payments-api. It does not open a shell or inspect an application's private log file. The relevant input is the process output written to stdout and stderr. A file inside the container appears here only if a separate collection path exposes it.

Batch retrieval versus streaming

Without a follow option, docker logs prints the available records and exits:

docker logs payments-api

Use this bounded snapshot to inspect startup failures, configuration errors, or the final messages before a process stopped. It is useful for a quick check, but the result represents what is available locally at query time.

For an active failure, attach to the stream:

docker logs --follow payments-api

Docker prints existing output first, then waits for new records. The short form is:

docker logs -f payments-api

Stop the stream after capturing the relevant evidence. The Ubuntu manpage for docker-logs documents --follow as disabled by default and describes the existing-output-then-follow behavior for stdout and stderr.

What the logging driver changes

docker logs reads through Docker's logging system. The configured logging driver therefore affects how records are stored and made available. Docker's documentation describes docker logs as able to read container logs across configured drivers or plugins, while the local driver can act as a cache for recent records.

That distinction matters during an investigation. The CLI gives you a practical host-local view, not a durable central archive. Treat the output as incident evidence only after recording timestamps, time boundaries, container identity, and the exact command used. If the investigation needs shared access, cross-service correlation, alerting, or retention beyond local storage, preserve the evidence in centralized Fluxtail streams through a documented collection path.

The working model is simple: identify the container, retrieve the output Docker exposes, and state clearly what the result cannot prove.

Docker Logs Flags Reference With Practical Examples

在事故處理中，先用單一旗標確認輸出範圍，再把旗標組合成可重現的查詢。每個旗標解決的問題不同，組合後才適合建立時間線。

持續取得新輸出

--follow 或 -f 會先輸出現有紀錄，然後保持連線等待新紀錄。預設值為停用。

docker logs --follow payments-api
docker logs -f payments-api

服務重啟、請求重試或設定變更後，這個旗標可用來觀察新的證據。取得需要的內容後，用終端機中斷控制停止串流，避免一直占用工作階段。

限制輸出行數

--tail 或 -n 只從輸出結尾取得指定行數。Docker 將預設值記為 all。

docker logs --tail 100 payments-api
docker logs -n 25 payments-api

較小的 tail 適合交接或即時檢查，可減少終端機雜訊。它只限制行數，不會依嚴重程度或訊息內容篩選。

加上時間戳記

--timestamps 或 -t 會在每筆紀錄前加上時間戳記：

docker logs --timestamps payments-api
docker logs -t payments-api

這讓容器輸出較容易和部署事件、主機活動及其他服務紀錄對照。若系統使用不同時鐘設定或時區，仍須先確認時間基準，再判讀先後順序。

設定起始時間

--since 會從指定的時間長度或時間戳記開始取得紀錄：

docker logs --since 15m payments-api
docker logs --since 2026-09-08T14:00:00 payments-api

已知告警或部署時間時，使用明確時間戳記有助於建立事件邊界。若調查是從現在開始，時間長度則較方便。Docker service logs reference 說明了 --since、時間戳記輸出與 tail 限制。

設定結束時間

--until 會在指定的時間長度或時間戳記停止取得紀錄：

docker logs --until 2026-09-08T14:30:00 payments-api

搭配 --since 使用時，兩者會形成固定範圍，方便保存查詢結果並交給其他值班工程師核對。

要求額外屬性

--details 會要求 Docker 在可用時附上與紀錄相關的額外資訊：

docker logs --details payments-api

輸出內容取決於 logging 設定提供的中繼資料。它不能取代應用程式本身寫入的結構化欄位，例如 request ID 或明確的 severity。若要形成可稽核的本地證據，可組合旗標：

docker logs --since 2026-09-08T14:00:00 --until 2026-09-08T14:30:00 --tail 200 --timestamps --details payments-api

這份結果仍是 Docker 在本機暴露的紀錄，不代表永久保存或集中收集。需要跨服務關聯或較長期留存時，應依已記錄的收集流程轉送至 Fluxtail streams。

Building Precise Time Windows for Debugging

A useful incident timeline rarely comes from one flag. The strongest local queries combine a start boundary, visible timestamps, and an output size appropriate to the question.

Start with a bounded live view

When a service is failing now, a small historical context followed by new entries keeps the terminal readable:

docker logs --tail 100 --follow --timestamps payments-api

--tail limits the initial context, --follow waits for new output, and --timestamps makes the stream easier to compare with alerts or deployment records. This combination is usually more useful than following an unbounded backlog during a noisy event.

For a one-time snapshot of the same context:

docker logs --tail 100 --timestamps payments-api

Reconstruct a known incident window

If an alert or deployment provides a start time, use --since with timestamps:

docker logs --since 2026-09-08T14:00:00 --timestamps payments-api

If the event has a clear end boundary, add --until:

docker logs \
  --since 2026-09-08T14:00:00 \
  --until 2026-09-08T14:30:00 \
  --timestamps \
  payments-api

This produces a bounded evidence slice for review or handoff. A line limit can be added when the team needs only the most recent portion of a window:

docker logs \
  --since 2026-09-08T14:00:00 \
  --until 2026-09-08T14:30:00 \
  --tail 200 \
  --timestamps \
  payments-api

Check the clock before interpreting results

Time filtering is only as trustworthy as the clocks used to interpret it. Responders should establish whether the supplied timestamp is understood in the intended time zone and compare container log timestamps with the host and incident tooling clocks. Client and host clock differences can make a narrow query appear to omit entries or include messages outside the expected event.

Evidence rule: Preserve the exact command, container identifier, host context, and time assumptions with any captured output. A log fragment without those details is harder to correlate later.

A local time slice helps investigate one container on one host. It doesn't automatically align records from other containers, normalize fields across services, or preserve the result after local rotation removes the underlying entries.

Working With Multiple Containers and Compose

Single-container commands become harder to read when an application has separate API, worker, and database services. The first decision is whether the incident requires the whole service group or only the component already identified as unhealthy.

For several known containers, the shell can run separate commands:

docker logs --timestamps --tail 100 api
docker logs --timestamps --tail 100 worker

For a live comparison, separate terminals can follow each service:

docker logs -f --timestamps api
docker logs -f --timestamps worker

This keeps each stream distinct. It also avoids pretending that interleaving from different commands represents a perfectly ordered cross-host timeline.

Compose service workflows

Compose projects usually provide a service-oriented view. To follow every service with a limited context:

docker compose logs --follow --tail 100 --timestamps

To focus on one service:

docker compose logs --follow --tail 100 --timestamps api

For a bounded handoff snapshot:

docker compose logs \
  --since 2026-09-08T14:00:00 \
  --until 2026-09-08T14:30:00 \
  --timestamps \
  api worker

The exact service names come from the Compose configuration. The service filter is valuable because a failing dependency can produce a large amount of unrelated output elsewhere in the project.

The Docker Compose logs guide provides a related workflow for viewing service output and narrowing multi-container investigations. Readability improves when timestamps are enabled, the initial line count is bounded, and the captured command records which services were included.

Make handoffs reproducible

An incident handoff should include the project or host context, selected services, time range, and whether the command followed live output. A responder can save a bounded snapshot for another engineer:

docker compose logs \
  --since 2026-09-08T14:00:00 \
  --until 2026-09-08T14:30:00 \
  --timestamps \
  api worker > incident-window.log

The file is an investigation artifact, not a centralized retention mechanism. For recurring cross-service analysis, collection should happen before an incident rather than relying on a responder to assemble fragments under pressure.

Log Storage Rotation and Driver Limits

Local Docker logs have a storage boundary determined by the engine and its logging configuration. The default logging driver is json-file, which stores per-container JSON records on the host and supplies the source read by docker logs in the default configuration. The Docker JSON file logging documentation defines the relevant rotation controls and their defaults.

Rotation settings that affect retention

The important settings are:

A daemon configuration can set rotation for the host:

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3",
    "compress": "true"
  }
}

The values in this example are configuration choices, not universal recommendations. Teams should select limits according to workload, disk capacity, incident needs, and their central collection path.

Why local logs aren't durable retention

With unlimited max-size by default, a production node can accumulate unbounded local log data unless rotation is configured. Rotation also means older entries may no longer be available through the local command, so a responder shouldn't assume that docker logs can reconstruct an earlier incident.

The local driver model has also changed over time. Historical documentation records a period when docker logs --follow worked only with the json-file driver, while Docker later expanded retrieval so the command could read logs across configured drivers or plugins, using a local cache for recent entries. That evolution improves inspection consistency, but it doesn't create an archive shared by every host.

Retention boundary: Rotation manages local disk growth. Central collection preserves searchable history and cross-container context. Neither function should be confused with the other.

The Docker container logs overview can help frame the difference between container output and a broader collection design. A sound production setup configures rotation to protect nodes and forwards relevant stdout and stderr to centralized storage before local retention becomes the only copy.

Forwarding Docker Logs to Fluxtail for Central Analysis

A centralized path should be explicit about what collects the logs, which protocol receives them, how credentials are scoped, and where records are routed. Docker's local command can provide immediate inspection, but it shouldn't be presented as a durable forwarding or retention layer.

Fluxtail supports a protocol-first ingestion model. Shared HTTP JSON and OTLP receivers use TLS on port 443 with receiver-bound Bearer credentials. Dedicated destinations are separate, including Syslog, GELF, StatsD, Fluent Forward, and Beats. Those paths shouldn't be conflated, because the receiver type determines the payload format and authentication details.

Use a collector rather than treating the CLI as a shipper

A production collector can read Docker container output and send structured records to the documented Fluxtail receiver. A generic shell pattern illustrates the separation of concerns without inventing an endpoint or payload schema:

docker logs --follow --timestamps payments-api |
  <documented-collector> --input stdin --output <documented-fluxtail-receiver>

The placeholders must be replaced with the collector and receiver configuration documented for the environment. A direct pipe can be useful for a controlled diagnostic, but a managed collector is generally the more appropriate place to handle parsing, metadata enrichment, buffering, and restart behavior. No retry, delivery, or retention guarantee should be inferred from the pipe itself.

The Fluxtail data ingestion example should be used to confirm the current receiver URL, payload, credential placement, and routing configuration before deployment. Public access and pricing are available by request and confirmed before setup.

Route records into named streams

Once received, logs can be routed into named streams that separate services or environments. The live tail view exposes fields such as timestamps, severity, stream, host, and message, giving responders a consistent surface for triage. Centralized records can then support filtering, analytics, alerts, built-in AI chat, and hosted MCP queries through compatible clients.

This model changes the incident question from “what remains on this host?” to “which stream contains the relevant evidence?” That is particularly useful when a failure crosses container boundaries or when the original container has restarted and local output is no longer sufficient.

Fluxtail is one centralized option for this documented workflow. It shouldn't be described as a permanent Free plan or as providing a trial unless current official product documentation explicitly confirms one.

Quick Reference for Docker Logs Command Options

The table below is designed for on-call copy-paste. Detailed behavior and combinations appear in the earlier sections.

Docker Logs Flags Quick Lookup

Common commands:

docker logs --tail 100 --timestamps CONTAINER
docker logs --since 15m --follow --timestamps CONTAINER
docker logs --since START --until END --timestamps CONTAINER
docker logs --details CONTAINER

Local versus centralized use

Conclusion and Next Steps With Fluxtail

The Docker logs command is a fast local inspection tool. Its strongest uses are focused snapshots, live following, timestamped correlation, bounded time windows, and readable multi-container checks. Rotation and logging-driver behavior define what remains available locally, so production teams shouldn't treat the command as durable centralized retention.

A practical operating sequence is:

1. Identify the container with docker ps -a.
2. Inspect a bounded, timestamped tail.
3. Combine --since and --until for a precise window.
4. Use Compose filters for service-level triage.
5. Configure rotation and forward important output centrally.
6. Verify current receiver and product behavior in Docker documentation and Fluxtail documentation as of September 2026.

Fluxtail provides centralized streams for forwarded container logs, with live tail, analytics, alerts, built-in AI chat, and hosted MCP access for compatible query workflows. Teams investigating beyond one host can visit Fluxtail to request access and confirm the current ingestion and pricing details.