What is a log?

A log, in software, is simply a running written record of events — a line of text describing something that happened, usually with a timestamp attached. A single application generates a “log” as an ongoing stream of these lines, one after another, describing what it did: a request it received, an error it hit, a task it completed.

What are Docker logs, specifically?

Docker logs are the captured output of whatever a container’s main process writes to two specific channels: standard output (often called “stdout,” normally used for regular informational messages) and standard error (often called “stderr,” normally used for error and warning messages). Docker automatically captures everything written to either of these channels and stores it, associated with that specific container, without the application needing to do anything special to enable this.

Why not just write logs to a file inside the container?

An application could technically write its own log messages to a file inside its own filesystem instead of printing them out, but that file would live inside the container’s writable layer, meaning it would vanish the moment the container is removed — the same ephemeral-storage problem that applies to any other data written inside a container. Printing to standard output and standard error instead lets Docker capture and store those messages independently of the container’s own filesystem, so the logs survive even after the container itself is gone.

Logging drivers

Docker does not hardcode a single way of storing logs; instead, it uses a pluggable “logging driver” system. The default driver on most installations writes logs to local JSON files on the host, one per container, but Docker supports many other drivers that can instead forward log output directly to specialized external logging systems, cloud logging services, or centralized log aggregation platforms used by larger companies.

Why this matters at scale

A company running only a handful of containers on one machine might be perfectly happy with the default local JSON file driver. A company running thousands of containers across many machines, however, needs those logs centralized somewhere a human can actually search across all of them at once — which is exactly why larger organizations typically configure a logging driver that ships log output straight to a centralized logging platform instead of leaving it scattered across many individual hosts.

flowchart LR
    APP["Container Process"] -->|writes lines to| STDOUT["stdout / stderr"]
    STDOUT -->|captured by| ENGINE["Docker Engine"]
    ENGINE -->|handed to| DRIVER["Logging Driver"]
    DRIVER -->|default| LOCAL["Local JSON Log File
(on host disk)"]
    DRIVER -->|alternative| REMOTE["Centralized Logging Platform
(remote system)"]
    LOCAL -->|read by| CMD["Log Retrieval Command"]
    REMOTE -->|searched via| DASH["External Dashboard"]
    

Capturing at the process level

When a container starts, Docker Engine connects the container’s main process’s standard output and standard error to a capture mechanism it controls, rather than letting them go directly to a terminal the way a normal program on your own computer would. Every single line the process writes to either stream is intercepted at this point, tagged with a precise timestamp, and passed along to whichever logging driver is configured.

Why the “main process” specifically matters

Docker only automatically captures output from the one main process it started for the container (technically, process ID 1 inside the container). If that application internally starts additional background processes that print their own separate output without funneling it back through the main process’s own streams, that additional output will not automatically appear in Docker’s captured logs at all — a common and confusing gap for beginners.

Timestamps and ordering

Docker records the exact time each line was captured, which is what allows logs to later be displayed strictly in chronological order, and allows filtering to a specific time window — extremely useful when trying to reconstruct exactly what an application was doing right before an incident occurred.

What an interviewer may ask

An interviewer may ask why an application’s internal log file does not show up when using Docker’s log commands. A strong answer explains that Docker only captures stdout and stderr of the container’s main process, so anything written elsewhere — an internal file, or output from an unrelated background process — falls outside what Docker automatically records.

The core trade-off is convenience versus durability. Docker’s built-in log capture is effortless and works identically everywhere, but by default it is only as durable as the container and host it lives on — genuinely durable, searchable, long-term logging requires deliberately configuring where that captured output ultimately ends up.

Sensitive data in logs

A very common and serious mistake is an application accidentally printing sensitive information — passwords, authentication tokens, personal customer details — directly into its own log output, because logs feel informal even though they are captured, stored, and often forwarded to systems with much broader access than the application itself. Once sensitive data lands in a log, it can persist far longer, and be seen by far more people, than the developer who wrote that print statement ever intended.

Who can read the logs

On the host, local log files are generally readable by anyone with sufficient host-level access, not just the team responsible for a specific application. In shared environments, this means teams need to be deliberate about who has access to raw log files versus a properly access-controlled centralized logging platform.

Log tampering and integrity

Because logs are often the primary evidence used to investigate an incident, some organizations forward logs to a separate, access-restricted system specifically so that even someone who compromises the application container cannot quietly edit or delete the historical record of what they did.

What an interviewer may ask

An interviewer may ask how to prevent sensitive data from leaking into application logs. A solid answer covers deliberately filtering or masking sensitive fields before logging, avoiding logging entire raw request or response objects, and restricting who and what has access to raw log storage.

Following logs live

Beyond simply reading past log history, Docker supports “following” a container’s logs, streaming new lines to the screen the instant they are written — extremely useful while actively debugging a container that is currently misbehaving, letting you watch its behavior unfold in real time rather than repeatedly checking after the fact.

Controlling log growth

Without limits, a chatty application can produce enormous amounts of log data, quietly filling up a host’s disk over time. Configuring maximum log file size and a maximum number of retained log files per container is a standard operational safeguard against this kind of silent disk exhaustion.

Centralized log aggregation

At real production scale, teams typically forward every container’s logs to a centralized logging platform, where logs from many different services and machines can be searched together, filtered by time range or keyword, and correlated with each other — something that is essentially impossible when logs are scattered across individual local files on dozens or hundreds of separate machines.

Pattern: structured logging

Rather than printing free-form sentences, many production applications print log lines in a consistent, structured format (commonly JSON), where each field — timestamp, severity, message, request identifier — is clearly labeled. Structured logs are dramatically easier for centralized logging platforms to search, filter, and correlate automatically compared to unpredictable free-text sentences.

Pattern: log everything to stdout, let the platform decide the rest

A widely followed principle, closely associated with the “Twelve-Factor App” methodology popularized in modern cloud-native application design, is that an application itself should never worry about where its logs end up — it should simply write everything to standard output and standard error, and leave the decision of storage, rotation, and forwarding entirely to the surrounding platform, which is exactly the role Docker’s logging drivers play.

Incident investigation

When a production outage occurs, engineering teams at companies large and small almost universally begin their investigation by pulling the relevant logs from the time window around the incident, reconstructing exactly what each affected service was doing right before things broke — logs are typically the very first evidence examined, ahead of almost anything else.

Netflix and large-scale observability

Netflix has publicly described building extensive internal observability tooling — logging, metrics, and tracing working together — precisely because at their scale, with an enormous number of services running simultaneously, no human could manually watch every container; centralized, searchable logs are what makes it possible to find the one relevant needle in an enormous haystack of running services.

Uber’s microservices logging

Uber’s engineering teams have written about the scale of their logging infrastructure, where thousands of individual services each produce continuous log output that must be collected, indexed, and made searchable, illustrating just how far the same basic idea — capture what a process prints, store it centrally, make it searchable — scales from a single laptop container all the way up to a global logistics platform.

Compliance and auditing

Regulated industries, including financial services and healthcare, often rely on retained, tamper-resistant logs as part of formal compliance and audit requirements, demonstrating not just that a system worked correctly, but providing a verifiable trail of exactly what happened and when.