docker compose logs

docker compose logs wyświetla logi kontenerów uruchomionych w ramach projektu Compose (czyli tego, co opisałeś w pliku compose.yaml). Zamiast skakać po pojedynczych kontenerach przez docker logs, dostajesz zbiorczy strumień ze wszystkich usług naraz, z prefiksem nazwy usługi przy każdej linii. To pierwsze narzędzie, po które sięgasz, gdy aplikacja „nie wstaje”, a Ty chcesz wiedzieć dlaczego.

Składnia i najważniejsze opcje

Podstawowa składnia: docker compose logs [OPTIONS] [SERVICE...]. Bez podania usługi zobaczysz logi wszystkich, z jedną lub kilkoma nazwami zawęzisz wynik do konkretnych kontenerów.

• -f, --follow — strumieniuje logi na żywo, dokładając nowe linie w miarę ich pojawiania się (przerywasz Ctrl+C).
• -n, --tail — pokazuje tylko ostatnie N linii, np. --tail 100; wartość 0 oznacza zero starych logów.
• -t, --timestamps — dokleja do każdej linii znacznik czasu ISO 8601, gdy aplikacja sama go nie wypisuje.
• --since — pokazuje logi od podanego momentu, np. --since 10m albo --since 2026-06-29T08:00:00.
• --until — pokazuje logi do podanego momentu; łączysz z --since, by wyciąć konkretny przedział.
• --no-color — wyłącza kolorowanie wyjścia (przydatne, gdy zapisujesz logi do pliku).
• --no-log-prefix — usuwa prefiks z nazwą usługi przed każdą linią.
• --index — wskazuje konkretną replikę usługi (numer instancji), gdy działa ich kilka.

Przykłady użycia

• docker compose logs — zrzuca dotychczasowe logi wszystkich usług projektu i kończy działanie.
• docker compose logs -f web — śledzi na żywo logi wyłącznie usługi web; idealne przy debugowaniu jednego komponentu.
• docker compose logs --tail 50 -f — pokazuje ostatnie 50 linii i od razu przechodzi w tryb live, bez zalewania terminala historią.
• docker compose logs --since 15m db — pokazuje tylko logi bazy z ostatniego kwadransa, gdy szukasz świeżego błędu.
• docker compose logs -t --no-color web worker > logi.txt — zapisuje logi dwóch usług ze znacznikami czasu do pliku, bez kodów kolorów.

Częste błędy i pułapki

Najczęstsza pomyłka to mylenie starej i nowej składni: docker-compose logs (z myślnikiem, Compose V1) działa nieco inaczej niż docker compose logs (V2, wbudowane w Docker CLI). Trzymaj się V2 — V1 jest wycofane.

Druga pułapka: jeśli kontener już nie istnieje (został usunięty przez docker compose down), jego logów nie zobaczysz — logs czyta tylko z istniejących kontenerów projektu. Po down historia znika.

Pamiętaj też, że logs czyta wyłącznie standardowe wyjście i błędów kontenera. Jeśli aplikacja pisze logi do pliku wewnątrz kontenera zamiast na stdout/stderr, tutaj ich nie znajdziesz — to nie wina komendy, tylko konfiguracji aplikacji. I jeszcze drobiazg: -f bez --tail najpierw wypluje całą historię, a dopiero potem zacznie strumieniować, więc przy długo działającym kontenerze poczekasz.

Powiązane komendy: docker logs (pojedynczy kontener), docker compose ps (status usług), docker compose up, docker compose events oraz docker compose top.