Docker logs filling your disk: diagnose before cleaning up

Author: OpsMate team
Updated 2026-10-14
Based on hands-on troubleshooting with OpsMate. Run commands only on servers you are authorized to access; replace paths and service names for your environment.

Docker’s default json-file logging driver does not rotate by default. Continuous stdout/stderr can fill host disk space or inodes until apps cannot write, health checks fail, or the site returns 5xx. Identify which filesystem is full and whether container logs are growing, then configure rotation in a maintenance window—do not wipe logs first and hide the cause.

These checks target Linux Docker Engine; Docker Desktop keeps engine data inside a VM.

1. Separate capacity from inode exhaustion

df -h
df -i
docker system df
docker info --format '{{.DockerRootDir}}'
docker inspect --format '{{.HostConfig.LogConfig.Type}} {{json .HostConfig.LogConfig.Config}}' YOUR_CONTAINER

Replace YOUR_CONTAINER with a container you are authorized to inspect. Check free bytes and free inodes. docker system df is not a substitute for inspecting container log files and cannot rule them out.

2. Find the source before removing evidence

docker inspect --format '{{.LogPath}}' YOUR_CONTAINER
docker logs --since 10m --tail 100 --timestamps YOUR_CONTAINER

If LogPath points to a local file, an authorized operator can check size with ls -lh. Some drivers have no local path. Do not edit, delete, or truncate Docker-managed log files directly. Keep relevant evidence and look for a repeated application error. Redact tokens, connection strings, and personal information before sharing.

If the real cause is business data or inodes rather than container logs, see Linux disk usage spike.

3. Plan rotation in a maintenance window

json-file does not rotate by default. This Compose example configures one service; it is not an emergency cleanup command:

services:
  app:
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"

Choose limits from container count, retention, and audit needs. Review and back up the existing configuration, get approval, then recreate affected containers with an interruption plan. Changing daemon defaults does not update existing containers. Afterward verify LogConfig, application health, and disk growth; keep the old config for rollback. See References for official docs.

Illustrative scenario: a dependency failure floods logs

Illustrative example (not a customer incident): repeated database connection failures generate dozens of lines per second and fill the disk. Freeing space alone will not stop recurrence. Fix the dependency, then set retention—do not discard all evidence to hide the cause.

Ask AI to organize the evidence

Check disk space, inodes, Docker log settings, and errors from the last ten minutes. Say whether the evidence supports log growth as the cause and what is still unknown. Do not delete files or recreate containers. Propose risks, verification, and rollback for my approval.

In OpsMate you can type the commands above or describe the symptom in plain language. The AI is mainly for troubleshooting. Commands that fail the safety check are blocked and never run. Low-risk fixes run automatically by default, and every step is logged. Each time you ask the AI for help, recent terminal output is sent to the cloud AI along with your message, so remove sensitive information first.

Try OpsMate

• Website: https://www.itops.sh/en/
• Sign up: https://app.itops.sh/login?screen=register&lang=en

500 free AI calls per month; no server limit. Desktop keeps SSH credentials on your machine by default.

References

• Configure logging drivers (Docker Docs) — default driver, daemon vs per-container settings
• JSON File logging driver — max-size / max-file rotation options
• df(1) — capacity vs inode checks

Troubleshooting guides