You open Dozzle to find out why the API fell over last night. The container has been recreated since. There is nothing to read.
Dozzle is not at fault. It never claimed to keep anything. Its README says so in one line: “It doesn’t store any log files—it’s designed purely for live log viewing.”
That sentence is the entire comparison. Everything below is detail.
Dozzle is free, MIT-licensed, and better at watching Docker logs than Central Logging is. It is also more capable than most people who have not used it lately assume.
It reads the Docker socket. No agent, no shipper, no configuration file — one docker run and every container on the host is there.
It groups multi-line stack traces, colour-codes detected JSON, and has an embedded SQL engine for ad-hoc queries over what is on screen.
It does alerting. Self-hosted, not only in the cloud product: log alerts with contains, startsWith, endsWith and regex matching, Docker event alerts that catch crashes and OOM kills without parsing anything, and container metric alerts. They deliver by webhook, with payload templates for the usual services.
It reaches other hosts through agent mode, and it works with Swarm, Kubernetes, Podman and Colima.
And the live view is genuinely good. Fuzzy container search, regex log search, a UI that does not make you think.
If you run Docker and you want to watch logs, install Dozzle. It is free and it is excellent, and nothing on this page argues otherwise.
The rest of this page is for the morning after.
Dozzle shows you what the Docker log driver still holds. That is not a Dozzle limit, it is where container logs live — and it has two sharp edges.
docker rm deletes the logs. The log file belongs to the container. Recreate the container on a docker compose up -d and last week is gone. This is the same problem covered in how to view Docker container logs, and it catches people who assume a log viewer implies log storage.
The default json-file driver does not rotate. max-size defaults to -1, unlimited, and max-file defaults to 1. So the file grows until the disk fills, and the usual fix — setting max-size — starts throwing history away at whatever size you pick. There is no setting that gives you both.
Dozzle is honest about the consequence. Its own README notes that it “doesn’t support offline searching.” A search only covers what is currently there to search.
And it is a Docker tool. Your journald, your nginx access log, your Postgres log, your cron jobs, the OPNsense box: Dozzle does not see them, because they are not containers.
| Dozzle | Central Logging | |
|---|---|---|
| Licence | MIT, free | $187 once |
| Deploy | Docker container, socket mounted | One binary |
| Sources | Docker, Swarm, Kubernetes, Podman | Anything that can POST over HTTP; the agent ships journald on Linux and syslog on OpenBSD |
| Live tail | Real-time streaming | 2-second poll, one source at a time |
| Stores logs | No | Yes, SQLite per source |
| Search history | No — live view only | Full-text and SQL over everything kept |
| Retention | Whatever the Docker log driver holds | Per source, in days |
| Alerting | Log, event and metric alerts by webhook | SQL and full-text rules, every 5 minutes |
| Alert on absence | No | Yes — a rule that returns no rows |
| Cron monitoring | No | Yes, with learned schedules |
| Uptime checks | No | Yes |
| Host inventory | Container metrics | Yes |
| Users | Multi-user file auth, forward proxy | Single admin account |
Two rows decide it. Dozzle wins the live tail. Central Logging is the only one of the two that can answer a question about yesterday.
Here is the split, concretely.
Dozzle answers: what is this container saying, right now, and tell me when it says something bad.
Central Logging answers: what did anything say between 03:10 and 03:20 last Tuesday.
SELECT datetime("timestamp", 'unixepoch') AS at, msg
FROM logs
WHERE "timestamp" BETWEEN strftime('%s','2026-09-09 03:10:00')
AND strftime('%s','2026-09-09 03:20:00')
ORDER BY "timestamp";
That query runs against a database on a different machine from the one that had the problem, which is the point. If the container is gone, if the host is gone, if the disk is gone, the lines shipped before it went are still there.
There is also a class of alert that live-only tooling cannot express: the one that fires when something stops happening. A rule that returns no rows is the signal — the nightly job that did not log “done”, the queue worker that went quiet at 02:00. Dozzle’s log alerts fire on a message appearing. Absence has no message.
This is the pairing that makes most sense of any on this site, because the two tools barely overlap.
Keep Dozzle for the live view — it is free, it is better at it, and a browser tab pointed at a running container is a genuinely different thing from a search box. Ship the same containers’ logs to Central Logging so that next week you can still read them.
Docker’s own logging drivers do the shipping; sending Docker container logs to a central server covers the options and their trade-offs. Nothing about that stops docker logs or Dozzle working, as long as you keep the local driver in place.
json_extract.POST from a shell script.Use Dozzle if your logging problem is “I want to see what the containers are doing” and a crash alert by webhook covers your monitoring. That is a real and common answer, and it is free.
Use Central Logging if you have been caught out by a recreated container, or if half your logs are not in Docker at all.
Use both if you run Docker seriously. They cost nothing to combine and they solve genuinely different problems.
Weighing a full log stack instead? Grafana Loki and the ELK stack are the heavier self-hosted comparisons, and OpenObserve is the closest single-binary one.
The free download is the complete product, not a trial. Point one container’s log driver at it and see whether being able to read last week changes anything.
14-day refund if you buy and it does not fit.
💌 Get notified on new features and updates