When a container misbehaves, its logs are often the fastest place to look. The trick is getting the right output without dumping an overwhelming amount of history—and knowing what Docker’s log command can and can’t show.
Start with recent output
For a single container, use docker logs with its name or ID:
docker logs --tail 100 CONTAINER
--tail 100 prints the latest 100 available lines. Adjust the number to fit the problem:
docker logs --tail 20 web
docker logs --tail 500 web
To print recent history and then watch for new messages, add -f (short for --follow):
docker logs --tail 100 -f web
This is handy when reproducing a startup failure or making a request that should produce an error. The command shows the recent context first, then waits for new output. Press Ctrl+C to stop following. This ends the log command, not the container.
You can also limit output by time. For example, to see entries from the last 10 minutes:
docker logs --since 10m web
Use a tail limit when you want a fixed amount of recent history; use --since when the time of the event is more useful than a line count.
Find the right container
The argument to docker logs must identify a container. It isn’t necessarily the image name or the service name from a Compose file.
List running containers:
docker ps
If the container has stopped, include stopped containers in the list:
docker ps -a
Use the name or ID shown in the output. For example:
docker logs --tail 100 -f web
If Docker says it can’t find the container, check the name or ID and confirm you’re using the Docker context where that container was created. A Compose service name is used with docker compose logs instead; the two commands target different kinds of identifiers.
Follow logs from Docker Compose
For a Compose-managed service, use docker compose logs and provide the service name from the Compose file:
docker compose logs --tail 100 -f api
To follow output from every service in the project, leave off the service name:
docker compose logs --tail 100 -f
This is useful when an issue crosses service boundaries—for example, when an API request depends on a database or another container. If the project is running in detached mode, learn what docker compose up -d does before deciding what to check next.
What Docker logs actually contains
docker logs displays output captured from a container’s standard output (stdout) and standard error (stderr). It doesn’t automatically show every log file inside the container.
If the application writes messages only to a file, Docker may show little or no application output even while that file contains logs. In that case, configure the application to write logs to standard output and error, or use the application’s intended method for accessing its log files.
This distinction helps avoid a common dead end: an empty docker logs result doesn’t necessarily mean the application produced no logs. It may mean the application sent them somewhere Docker isn’t displaying through this command.
Common surprises
Following appears to hang
That’s normal when the container hasn’t written anything new. With -f, Docker waits for the next log entry. Check whether the application is running and producing output, or trigger an action that should generate a message. Use Ctrl+C when you’re done waiting.
The output is too large
Add --tail to limit the initial history. Without a limit, Docker can print a large amount of existing output before you reach the new messages you’re waiting for.
To show the first 100 lines rather than the last 100, pipe the output to head:
docker logs web | head -n 100
You need to inspect the container, not its logs
Logs are for reading captured output. They don’t open a shell or run a command inside the container. For that, use docker exec; see how to run commands in a running container.
A simple debugging loop
When investigating a container, start by identifying it with docker ps or docker ps -a. Then read a manageable slice of recent output:
docker logs --tail 100 CONTAINER
If you’re reproducing the issue, follow new output:
docker logs --tail 100 -f CONTAINER
For a Compose project, use docker compose logs with a service name—or omit the service name to follow all services. If expected messages are missing, check whether the application writes to stdout and stderr or only to an internal file.
These small distinctions make log checks quicker: pick the right container or service, limit the history, and remember that following output waits for new messages rather than stopping the container.
I originally published a more detailed version of this guide on the SSHFlow blog.
I'm also building SSHFlow — an SSH client where every server gets its own workspace for terminals, SFTP, code, and databases.
Top comments (0)