15.1.3.1 Missing Container Logs

Missing container logs describes the specific situation where a container's log output is entirely unavailable, not merely incomplete or delayed, and the most common root causes are tied to specific lifecycle and configuration decisions rather than an unpredictable or mysterious failure of Docker's logging system itself.

The container was removed before logs were read

The most frequent cause of genuinely missing logs is that the container itself no longer exists; Docker's log storage for the json-file and local drivers is tied directly to the container's own lifecycle, and removing a container deletes its log file along with everything else associated with it:

docker run --rm -d --name my-api my-api:1.4.0
docker rm -f my-api
docker logs my-api

Error: No such container: my-api

The --rm flag is a particularly common contributor to this problem: it automatically removes the container, and therefore its logs, the moment it stops, which means any failure investigation needs to happen before the container exits, or logs need to be captured through a separate mechanism (redirected output, a collector reading in real time) rather than relying on docker logs after the fact.

docker run --rm my-api:1.4.0 npm run migrate 2>&1 | tee -a migration-output.log

The logging driver does not support local read-back

A configuration choice rather than a failure, certain drivers (syslog, fluentd, gelf, awslogs, and others) never retain a locally queryable copy of log output, which means docker logs reports an explicit error rather than empty output:

docker logs my-api

Error response from daemon: configured logging driver does not support reading

This is resolved either by querying the actual configured destination directly (the remote syslog server, the Fluentd-fed aggregation system) or by enabling Docker's dual logging feature to retain a local cache alongside the remote driver.

The application never wrote to stdout or stderr at all

If an application writes its own logs to a file inside the container rather than to the standard streams Docker captures, docker logs will show nothing at all, even though the application itself may be logging extensively from its own perspective:

docker exec my-api ls -la /app/logs/
docker exec my-api cat /app/logs/app.log

Confirming whether the application is writing to an internal file path, rather than concluding the logging pipeline itself is broken, often resolves this quickly; the fix is either reconfiguring the application to log to stdout and stderr directly, or explicitly tailing the internal file path as part of the container's own startup command.

CMD ["sh", "-c", "tail -F /app/logs/app.log"]

The container crashed before producing any output

A container that fails immediately on startup, before the application has a chance to write anything, can appear to have no logs simply because nothing was ever written, rather than because logging itself failed:

docker logs my-api
docker inspect --format='{{.State.ExitCode}}' my-api
docker inspect --format='{{.State.Error}}' my-api

Checking the exit code and any daemon-recorded error message directly, rather than relying solely on application-level logs that may never have been produced, is necessary in this case, since the failure happened too early in the application's lifecycle for its own logging to have engaged at all.

Log rotation removed the relevant history

For a long-running container, the specific log entries being searched for may simply have rotated out of retention before anyone went looking for them, particularly if rotation limits were configured conservatively relative to actual log volume:

docker inspect --format='{{.HostConfig.LogConfig.Config}}' my-api

ls -la /var/lib/docker/containers/*/$(docker inspect --format='{{.Id}}' my-api)*.log*

If a centralized aggregation system is in place and was collecting logs continuously, the missing history may still be recoverable there even though it has rotated out of local storage, which is one of the practical arguments for centralized aggregation beyond convenience: it provides a retention window independent of local rotation limits.

Permissions or daemon configuration prevented capture

In less common cases, a misconfigured logging driver path, insufficient permissions on a mounted log directory for a remote driver requiring local buffering, or a daemon restart at an inopportune moment can prevent log capture from functioning correctly at all:

journalctl -u docker.service | grep -i log

docker info --format '{{.LoggingDriver}}'

Checking the Docker daemon's own logs for errors related to the logging driver itself is a reasonable step when application-level explanations have been ruled out and logs remain unexpectedly absent.

Preventive practices to avoid missing logs

Several practices reduce how often missing logs become a genuine investigative dead end: avoiding --rm for containers where post-mortem log inspection might be needed, ensuring critical containers use a driver that supports local read-back or has dual logging enabled, and shipping logs to centralized aggregation continuously rather than relying solely on local, rotation-bound storage.

docker run -d --log-driver=local --log-opt max-size=20m --log-opt max-file=5 my-api

docker compose logs --no-color -f api | tee -a /var/log/api-stream.log

Common mistakes

• Using --rm on a container whose logs might be needed for post-mortem investigation, losing them automatically the moment the container exits.
• Concluding the logging system is broken before checking whether the configured driver supports local reading at all.
• Assuming an application that produces no docker logs output is failing silently, without first checking whether it writes to an internal file instead of to stdout and stderr.
• Searching only local log storage for historical entries that may have already rotated out, without checking whether a centralized aggregation system retained them independently.
• Not checking the container's exit code and daemon-recorded error for a container that crashed too early to have produced any application-level log output at all.

Missing container logs are almost always traceable to one of a small number of specific, identifiable causes, container removal, an unsupported driver, an application writing to the wrong destination, rotation, or an early crash, rather than an unexplainable failure of Docker's logging system itself, and working through these specific possibilities in order is generally faster than treating the absence as a mystery.