How to View Docker Container Logs - A Complete Step-by-Step Guide (2026)
Docker containers generate large volumes of logs, but learning how to view them efficiently can be challenging without the right approach. Whether you're debugging a failing deployment, monitoring application performance, or investigating security incidents, mastering container logs management is fundamental to maintaining healthy containerized systems.
This guide walks you through Docker container logging from basic commands to production-ready strategies, including integration with observability platforms for comprehensive log analysis.
Understanding Docker's Logging Architecture
Docker logs capture all output from containerized applications that write to standard output (stdout) and standard error (stderr) streams. This follows the twelve-factor app principle, which states that applications should treat logs as event streams written to the console rather than managing log files internally.
When containers generate output, Docker automatically captures container logs using configurable logging drivers. The system stores logs with metadata including timestamps, stream origin (stdout/stderr), and message content. By default, Docker uses the JSON-file logging driver, which stores container logs in JSON format at /var/lib/docker/containers/<container-id>/<container-id>-json.log.
Basic Docker Log Commands
Let's start with a practical example. Create a test container to follow along:
docker run -d --name test-nginx nginx:latestList all running containers:
docker psIf a container has stopped, use docker ps -a to find it. You can still read its retained logs until the container is removed.
View Container Logs
The most basic docker logs command retrieves all available logs from the container:
docker logs test-nginx
To view logs of a specific container, you can either use the container name or ID:
docker logs 1a2b3c4d5e6fReal-Time Log Streaming
For active monitoring, use the --follow flag to stream logs as they're generated:
docker logs --follow test-nginx
This is essential for troubleshooting active issues or monitoring deployments. Press Ctrl+C to stop streaming.
Add --timestamps to include the time of each entry when comparing activity across containers:
docker logs --follow --tail 100 --timestamps test-nginxLimiting Log Output
When you need to view Docker container logs selectively, use --tail to view only recent entries:
docker logs --tail 50 test-nginxCombine with --follow for continuous monitoring of recent activity:
docker logs --tail 20 --follow test-nginxAdvanced Log Filtering and Analysis
Docker provides powerful filtering options for precise log analysis, particularly valuable in production environments with high log volumes.
Time-Based Filtering
Use the --since & --until to filter logs for specific time windows when investigating incidents or analyzing patterns:
docker logs --since "2025-01-20T10:00:00" --until "2025-01-20T12:00:00" test-nginxDocker accepts ISO 8601 timestamps and relative time specifications:
docker logs --since "24h" test-nginx # Last 24 hours
docker logs --since "2h30m" test-nginx # Last 2 hours and 30 minutes
docker logs --since "15m" test-nginx # Last 15 minutesPattern Matching and Text Processing
Combine docker logs with Unix text processing tools for powerful analysis:
docker logs test-nginx 2>&1 | grep -i "error" # Case-insensitive error search
docker logs test-nginx 2>&1 | grep -E "(error|warning)" # Multiple patterns
docker logs test-nginx 2>&1 | grep -B 5 -A 5 "timeout" # Context around matchesChain multiple filters for sophisticated analysis:
docker logs --since "1h" test-nginx 2>&1 | grep "POST" | wc -l # Count POST requests in last hourExporting Logs
Export Docker container logs for offline analysis or sharing:
docker logs test-nginx > nginx_logs.txt 2>&1 # Save all logs
docker logs --since "24h" test-nginx > recent_logs.txt 2>&1 # Save recent logs
docker logs test-nginx 2>&1 | tee analysis.log # Save while viewingThe 2>&1 redirection combines stdout and stderr, while tee displays logs on the screen and saves them to a file.
Multi-Service Log Analysis
For applications managed with Docker Compose, run the following commands from the directory containing your Compose file. Use service names such as web and database from that file when selecting logs:
docker compose logs # All services
docker compose logs web database # Specific services
docker compose logs --tail=100 --follow # Real-time monitoringThe --tail limit applies to each container. To investigate recent activity in one service and keep watching for new entries, combine the filters:
docker compose logs --since 30m --tail 100 --timestamps --follow webFor a fixed incident window, use --since and --until together. Use --no-color when saving Compose output to a file, and --index 2 web to select the second container when the web service has multiple replicas.
View Docker Compose Healthcheck Logs
If a service is running but marked unhealthy, inspect its healthcheck output to see why the check is failing. Healthcheck output is stored separately from the application logs shown by docker compose logs.
First, find the container name or ID for the service:
docker compose ps -a webFor a container with a configured healthcheck, replace container_name below with that name or ID:
docker inspect --format='{{json .State.Health}}' container_nameThe Status field shows whether the container is starting, healthy, or unhealthy. Recent entries in Log include each check's ExitCode and Output. A connection error or timeout here can explain a failed check even when the application logs are quiet. If failures happen during startup, check whether start_period gives the service enough time to initialize before failures count toward retries.
View Docker Swarm Service Logs
For Docker Swarm services using the json-file or journald driver, run this command on a Swarm manager node:
docker service logs --follow --tail 100 service_nameReplace service_name with your service's name or ID. This combines output from its containers across the swarm so you can follow activity across replicas.
Access Logs Through the Docker API
For scripts that need logs without calling the Docker CLI, the Docker Engine API provides a container logs endpoint. On a Linux host using the default Docker socket and a container with the json-file driver, this request retrieves the last 100 lines from both output streams:
curl --unix-socket /var/run/docker.sock \
"http://localhost/containers/test-nginx/logs?stdout=true&stderr=true&tail=100"For containers without a TTY, the response includes binary headers that identify the output stream. Use a Docker SDK to decode that response when processing log messages in an application.
Troubleshooting Common Logging Issues
Empty or Missing Logs
Application writes to files instead of console: Many applications log to files inside containers rather than stdout/stderr. Docker only captures console output.
Solution: Configure applications to log to stdout/stderr, or use symbolic links:
# Inside Dockerfile
RUN ln -sf /dev/stdout /var/log/nginx/access.log
RUN ln -sf /dev/stderr /var/log/nginx/error.logOutput buffering: Programming languages often buffer output, preventing immediate log visibility.
Solution: Disable buffering through environment variables:
docker run -e PYTHONUNBUFFERED=1 my-python-appIncorrect logging driver: Some drivers don't support docker logs command.
Solution: Check the logging driver and enable dual logging if needed:
docker inspect container_name --format='{{.HostConfig.LogConfig.Type}}'Inspect Running Processes When Logs Are Not Enough
Application logs show what a process writes, but they do not list every process running inside the container. If logs stop unexpectedly, check which processes are still running:
docker top test-nginxThis gives you a current process snapshot. To save it for an incident report, run docker top test-nginx > container_processes.txt. If the image includes ps, you can also inspect processes from inside the running container:
docker exec test-nginx ps -efThese commands do not record process history. For ongoing visibility, configure each application process, or its process manager, to send output to the container's stdout and stderr so Docker can capture it.
Log Rotation Issues
Insufficient retention: Default settings may rotate logs too aggressively.
Solution: Adjust rotation parameters in /etc/docker/daemon.json:
{
"log-driver": "local",
"log-opts": {
"max-size": "50m",
"max-file": "10"
}
}No rotation: Some configurations lack proper rotation, leading to disk exhaustion.
Solution: Always configure appropriate log rotation and monitor disk usage.
Permission Problems
Use sudo when necessary or add your user to the Docker group (consider security implications):
sudo docker logs container_nameDocker Logging Configuration
Logging Driver Options
json-file (Default): Stores logs as JSON files. Simple but lacks advanced features.
local (Recommended): Optimized file-based driver with better performance, compression, and efficient storage.
syslog: Integrates with system logging services for centralized management.
journald: Forwards logs to systemd journal on supported systems.
fluentd: Routes logs to Fluentd collectors for flexible processing.
awslogs: Directly sends logs to AWS CloudWatch.
Global Configuration
Configure default logging behaviour in /etc/docker/daemon.json:
{
"log-driver": "local",
"log-opts": {
"max-size": "25m",
"max-file": "5",
"compress": "true"
}
}On Linux hosts using systemd, restart Docker after configuration changes:
sudo systemctl restart dockerThe new defaults apply to newly created containers. Recreate existing containers to use the updated logging configuration.
Per-Container Configuration
Override default Docker settings to customize how you view container logs for specific containers:
docker run -d \
--log-driver local \
--log-opt max-size=10m \
--log-opt max-file=3 \
--name custom-logs \
nginx:latestFor Docker Compose:
version: '3.8'
services:
web:
image: nginx:latest
logging:
driver: local
options:
max-size: "15m"
max-file: "7"
compress: "true"Blocking and Non-Blocking Log Delivery
By default, Docker delivers logs in blocking mode. If the logging driver cannot keep up, the application's log writes can block. Non-blocking mode uses a buffer so the application can continue, but drops new log messages when that buffer fills.
To select non-blocking delivery for a new container:
docker run -d --log-driver local \
--log-opt mode=non-blocking \
--log-opt max-buffer-size=4m \
--name buffered-logs nginx:latestChoose this mode when keeping the application responsive matters more than retaining every log message.
Production Best Practices
Storage Management
Monitor Docker log directory usage and alert before storage fills:
# Monitor log directory usage
du -sh /var/lib/docker/containers/Use Docker's rotation settings to manage these files rather than deleting them directly. Export logs to centralized or archival storage before local retention removes entries you need to keep.
Configure rotation to balance retention needs with storage:
{
"log-driver": "local",
"log-opts": {
"max-size": "25m",
"max-file": "5"
}
}Security Considerations
- Ensure applications don't log sensitive data (passwords, API keys, PII)
- Restrict access to log directories and consider encryption
- Implement clear log retention policies for compliance
Performance Optimization
- Choose appropriate logging drivers based on requirements
- Configure applications with suitable log levels for production
- Use asynchronous logging frameworks to prevent bottlenecks
Centralized Logging Strategy
Standardize log formats: Use structured logging (JSON) for better machine readability:
// Example structured logging
console.log(JSON.stringify({
timestamp: new Date().toISOString(),
level: 'info',
service: 'web-api',
message: 'User authentication successful',
userId: 'user123',
requestId: 'req-456'
}));Implement correlation: Use correlation IDs to connect related log entries across containers.
Centralized Log Management with SigNoz
For production environments where you need to view container logs at scale, centralized log management platforms like SigNoz provide advanced analysis capabilities beyond basic Docker commands.
SigNoz offers comprehensive log management built on OpenTelemetry standards, providing fast log ingestion, advanced querying, and trace-to-log correlation through a unified interface.
Key Features for Docker Environments
OpenTelemetry-native collection: Avoids vendor lock-in while supporting extensive log ingestion from Docker containers through the OpenTelemetry Collector.
High-performance storage: The columnar datastore as backend supports fast log analysis and low-latency queries at scale.
Advanced query builder: Intuitive interface for searching and filtering logs with dropdown-based filters, aggregations, and mathematical functions for complex analysis.
Setting Up Docker Log Collection
SigNoz enables you to view container logs centrally through a pre-configured setup using the OpenTelemetry Collector to collect logs:
- Clone the repository:
git clone https://github.com/SigNoz/docker-container-logs- Configure environment variables in the
.envfile:
OTEL_COLLECTOR_ENDPOINT=ingest.<region>.signoz.cloud:443
SIGNOZ_INGESTION_KEY=<your-ingestion-key>- Start the collector:
docker compose up -dThis setup automatically forwards all logs to SigNoz, allowing you to view them centrally with minimal configuration changes to your existing deployments.

Advanced Capabilities
- Create saved views for common troubleshooting scenarios
- Build custom dashboards correlating logs with metrics and traces
- Set up dynamic alerting based on log patterns
- Use powerful query capabilities with both PromQL and ClickHouse syntax
Get Started with SigNoz
SigNoz provides comprehensive log management capabilities, including an advanced query builder for Docker environments. The platform offers fast log ingestion, correlation with metrics and traces, and powerful visualization features.
You can choose between various deployment options in SigNoz. The easiest way to get started with SigNoz is SigNoz Cloud. We offer a 30-day free trial account with access to all features.
Those with data privacy concerns and can't send their data outside their infrastructure can sign up for either the enterprise self-hosted or BYOC offering.
Those who have the expertise to manage SigNoz themselves, or who just want to start with a free, self-hosted option, can use our community edition.
Hope we answered all your questions regarding Docker container logging. If you have more questions, feel free to use the SigNoz AI chatbot, or join our Slack community.
Key Takeaways
Effective Docker logging requires understanding the architecture, using appropriate commands for different scenarios, and implementing production-ready configurations. Key points to remember:
- Use the
localdriver for most production environments - Configure appropriate log rotation to prevent storage issues
- Implement structured logging with correlation IDs for better analysis
- Consider using observability platforms like SigNoz for advanced log analysis and the ability to view container logs across your entire infrastructure
Docker’s native logging features, combined with observability platforms like SigNoz, provide centralized visibility into containerized workloads. Efficiently collecting and analyzing container logs at scale helps teams troubleshoot issues faster and improve operational reliability.