uptime to jednolinijkowe polecenie, które w jednej sekundzie mówi ci, jak długo maszyna nie widziała reboota i czy właśnie się dusi pod obciążeniem. Wypluwa aktualny czas, czas działania systemu (czyli słynny uptime), liczbę zalogowanych użytkowników oraz load average z ostatnich 1, 5 i 15 minut. To pierwsze polecenie, które adminzy wpisują po zalogowaniu na obcy serwer, żeby wyrobić sobie zdanie, zanim zaczną grzebać głębiej.
Składnia i najważniejsze opcje
Podstawowa forma jest banalna: uptime [opcje]. Bez żadnych flag dostajesz pełną, klasyczną linijkę. Najważniejsze przełączniki (wersja z pakietu procps-ng):
-p,--pretty— pokazuje sam czas działania w czytelnej formie, np. „up 3 weeks, 2 days, 4 hours, 12 minutes”, bez load average i użytkowników.-s,--since— wypisuje moment, od którego system działa, w formacieyyyy-mm-dd HH:MM:SS. Świetne, gdy chcesz poznać dokładną datę ostatniego startu.-h,--help— krótka pomoc z listą opcji.-V,--version— wersja narzędzia i tyle.
To realnie cały zestaw — uptime nie jest kombajnem z dziesiątkami flag i o to w tym chodzi.
Przykłady użycia
uptime— pełna linijka: godzina, czas działania, liczba użytkowników i trzy wartości load average. Twój domyślny szybki rzut oka.uptime -p— samo „up 5 days, 3 hours, 21 minutes”. Idealne do skryptów albo raportu dla kogoś, kogo load average nie interesuje.uptime -s— wypisze coś w stylu2026-06-12 08:42:15, czyli dokładny moment startu systemu. Przydaje się przy sprawdzaniu, kiedy poszedł restart.watch -n 5 uptime— odświeża wynik co 5 sekund, żeby na żywo obserwować, jak load average rośnie podczas obciążenia (np. w trakcie deploya lub backupu).uptime && who— łączysz uptime z listą zalogowanych, żeby od razu zobaczyć, kto siedzi na maszynie.
Częste błędy i pułapki
Największa pułapka to interpretacja load average. To nie procent zajętości CPU. Wartość 1.0 oznacza pełne obciążenie jednego rdzenia — więc na serwerze z 4 rdzeniami load 1.0 to spokój, a na jednordzeniowej maszynie to sufit. Zawsze dziel load przez liczbę rdzeni (nproc), zanim wpadniesz w panikę.
Druga rzecz: load liczy nie tylko procesy walczące o CPU, ale też te w stanie uninterruptible, czyli czekające na dysk lub sieć. Dlatego wysoki load przy niskim zużyciu procesora zwykle oznacza wąskie gardło na I/O, a nie przeciążony CPU.
Trzecia: flagi -p i -s to dodatek z procps-ng. Na starszych systemach, macOS czy w minimalnych obrazach (np. BusyBox) uptime może ich nie mieć i zwróci błąd — nie zakładaj z góry, że wszędzie zadziałają.
Powiązane komendy: top, htop, w, who, free, vmstat, mpstat, nproc.