The 'Timeout after 60 seconds' error in Docker Compose occurs when the Docker daemon doesn't respond within the default 60-second window. This is typically caused by slow network conditions, resource-intensive builds, unresponsive healthchecks, or Docker daemon performance issues.
The "Timeout after 60 seconds" error indicates that Docker Compose waited for a response from the Docker daemon but did not receive one within the allotted time. The full error message often appears as: ``` ERROR: An HTTP request took too long to complete. Retry with --verbose to obtain debug information. If you encounter this issue regularly because of slow network conditions, consider setting COMPOSE_HTTP_TIMEOUT to a higher value (current value: 60). ``` Docker Compose communicates with the Docker daemon via HTTP requests over a Unix socket (or TCP on Windows). When operations like starting containers, building images, or pulling dependencies take longer than 60 seconds, Compose considers the request failed and terminates. This timeout is not about container startup time but rather about the HTTP communication channel between docker-compose and the Docker daemon. Heavy operations, slow disk I/O, or an overloaded Docker daemon can trigger this error. **Important:** In Docker Compose V2 (the default in modern Docker installations), the `COMPOSE_HTTP_TIMEOUT` environment variable is deprecated and no longer has an effect. You must use the `--timeout` flag or address the underlying cause instead.
For Docker Compose V1, increase the HTTP timeout using environment variables:
# Set environment variables before running docker-compose
export DOCKER_CLIENT_TIMEOUT=120
export COMPOSE_HTTP_TIMEOUT=120
docker-compose up -dOr create a .env file in your project directory:
COMPOSE_HTTP_TIMEOUT=120Note: This only works with Docker Compose V1. For V2, see the next step.
In Docker Compose V2, the environment variable is deprecated. Use the --timeout flag instead:
# Set timeout to 120 seconds
docker compose --timeout 120 up -d
# Or for builds
docker compose --timeout 300 buildCheck your Compose version:
docker compose versionIf you see "Docker Compose version v2.x.x", you're using V2.
Sometimes the Docker daemon becomes unresponsive. Restarting it often resolves timeout issues:
# Linux
sudo systemctl restart docker
# More thorough cleanup
sudo systemctl restart docker && sudo docker system prune -afDocker Desktop (Windows/Mac):
1. Right-click the Docker icon in the system tray
2. Select "Restart Docker Desktop"
Or from the command line on Mac:
killall Docker && open /Applications/Docker.appStale container state can cause timeouts. Clean up before starting:
# Stop and remove containers, networks
docker-compose down
# Then start fresh
docker-compose up --build -dFor a more thorough cleanup:
# Remove containers, networks, and volumes
docker-compose down -v
# Remove orphan containers too
docker-compose down --remove-orphansHealthcheck timeouts can cascade into compose timeouts. Adjust your healthcheck settings:
services:
db:
image: postgres:15
healthcheck:
test: ["CMD-SHELL", "pg_isready -U postgres"]
interval: 10s
timeout: 5s
retries: 5
start_period: 30s # Grace period before checks countKey settings:
- start_period: Time to wait before health checks count against retries
- interval: Time between health checks
- timeout: Maximum time for each health check
- retries: Number of consecutive failures before unhealthy
For services that take a long time to initialize, increase start_period:
healthcheck:
test: curl --fail http://localhost:8080/health || exit 1
interval: 30s
timeout: 10s
retries: 3
start_period: 60s # Give app 60s to start before checkingStarting too many containers at once can overwhelm Docker. Use depends_on to serialize startup:
services:
db:
image: postgres:15
healthcheck:
test: ["CMD-SHELL", "pg_isready -U postgres"]
interval: 5s
timeout: 5s
retries: 5
start_period: 10s
app:
build: .
depends_on:
db:
condition: service_healthy # Wait for db to be healthyOr start services in batches:
# Start infrastructure first
docker-compose up -d db redis
# Wait for them to be ready, then start app services
docker-compose up -d app workerThe tty: true setting in docker-compose.yml can cause timeout issues in some configurations:
services:
app:
image: myapp
# Remove or comment out this line if experiencing timeouts
# tty: trueIf you need TTY for interactive use, only enable it when running interactively:
docker-compose run --rm app /bin/bashAn overloaded Docker daemon can cause timeouts. Check its resource usage:
# Check Docker disk usage
docker system df
# View detailed breakdown
docker system df -v
# Check running containers and their resource usage
docker stats --no-streamFree up resources if needed:
# Remove unused containers, images, networks, and build cache
docker system prune -a
# Also remove unused volumes (WARNING: data loss)
docker system prune -a --volumesDocker Desktop: Increase allocated memory and CPU in Settings > Resources.
Image pulls can take a long time and contribute to timeouts. Pull images first:
# Pull all images defined in docker-compose.yml
docker-compose pull
# Then start (without needing to pull)
docker-compose up -dFor CI/CD pipelines, cache base images or use a registry mirror to speed up pulls.
### Compose V1 vs V2 Timeout Behavior
Compose V1 (docker-compose, Python-based):
- Uses COMPOSE_HTTP_TIMEOUT environment variable
- Default timeout: 60 seconds
- Can be set via .env file
Compose V2 (docker compose, Go-based):
- COMPOSE_HTTP_TIMEOUT is deprecated and ignored
- Use --timeout flag on individual commands
- Better performance and typically fewer timeout issues
Check your version:
# V1 shows: docker-compose version 1.x.x
docker-compose version
# V2 shows: Docker Compose version v2.x.x
docker compose version### Healthcheck Timeout vs HTTP Timeout
These are different timeout types:
1. HTTP Timeout (COMPOSE_HTTP_TIMEOUT): Communication between docker-compose and Docker daemon
2. Healthcheck Timeout: How long to wait for a health check command to complete
3. depends_on Timeout: How long to wait for dependent services to become healthy
When using depends_on with condition: service_healthy, Compose will wait indefinitely (or until the HTTP timeout) for the service to become healthy. Configure reasonable healthcheck parameters to avoid this.
### Debugging Timeout Issues
Enable verbose output to see what's happening:
docker-compose --verbose upCheck Docker daemon logs:
# Linux with systemd
sudo journalctl -u docker -f
# Docker Desktop
# Open Docker Desktop > Troubleshoot > Show Docker Desktop log### CI/CD Considerations
In CI/CD environments, timeouts are common due to:
- Cold image caches requiring full pulls
- Shared runners with resource contention
- Network variability
Mitigation strategies:
1. Use CI-specific Docker image caching
2. Pre-build and push images to a registry
3. Use service containers instead of docker-compose where possible
4. Implement retry logic in your CI scripts
### Alternative: Use Docker Compose Watch
For development, Docker Compose Watch (V2.22+) can avoid restart-related timeouts:
services:
app:
build: .
develop:
watch:
- action: sync
path: ./src
target: /app/src
- action: rebuild
path: package.jsonRun with:
docker compose watchThis syncs file changes without restarting containers, avoiding timeout-prone restart cycles.
image operating system "linux" cannot be used on this platform
How to fix 'image operating system linux cannot be used on this platform' in Docker
manifest unknown: manifest unknown
How to fix 'manifest unknown' in Docker
cannot open '/etc/passwd': Permission denied
How to fix 'cannot open: Permission denied' in Docker
Error response from daemon: failed to create the ipvlan port
How to fix 'failed to create the ipvlan port' in Docker
toomanyrequests: Rate exceeded for anonymous users
How to fix 'Rate exceeded for anonymous users' in Docker Hub