When a Docker Compose service exits early, restarts, or appears stuck, the service log is usually the fastest proof of what the container process actually wrote. Compose keeps the service name and replica prefix attached to each line, which helps separate one service from another in a shared project.
docker compose logs reads output from the containers in the current Compose project. It can show all services or a selected service, with enough project context to keep each line tied to the container that produced it.
The command must target the same Compose project that started the containers. A clean log read proves what was emitted, but it does not prove the service is healthy unless the log line is tied to the expected application state.
$ cd /srv/example-stack
$ docker compose ps --services app worker db
$ docker compose logs --no-color --tail=50 app app-1 | app started app-1 | listening on 0.0.0.0:8080 app-1 | processing item 42
--no-color keeps copied evidence readable in tickets and change records.
$ docker compose logs --no-color --since=15m app app-1 | 2026-06-16T04:50:11Z request completed status=200 path=/health app-1 | 2026-06-16T04:51:04Z request completed status=200 path=/api/items
$ docker compose logs --no-color --follow --tail=20 app app-1 | app started app-1 | listening on 0.0.0.0:8080
Stop the follow stream with Ctrl-C after the expected line appears.
$ docker compose ps app NAME IMAGE COMMAND SERVICE STATUS PORTS example-stack-app-1 registry.example/app:1.0 "/entrypoint.sh" app Up 2 minutes 0.0.0.0:8080->8080/tcp