Uptime Kuma: monitoring strony i VPS za darmo

Strona może ładować się poprawnie na Twoim laptopie, a jednocześnie nie działać dla klientów. API może odpowiadać kodem 500, chociaż serwer VPS nadal „żyje”. Certyfikat SSL może wygasnąć w sobotę wieczorem. Backup może przestać się wykonywać, bo ktoś zmienił ścieżkę, hasło albo uprawnienia do katalogu. To nie są awarie z kategorii „kiedyś może się zdarzą”. To zwykła codzienność małych firm, sklepów, stron na WordPressie i aplikacji utrzymywanych na VPS-ach.

Uptime Kuma rozwiązuje prosty problem: sprawdza, czy usługi działają, i wysyła powiadomienie, zanim użytkownik napisze na Messengerze „strona nie działa”. Nie zastępuje pełnego monitoringu infrastruktury, logów, APM ani obserwowalności klasy enterprise. Ale dla strony firmowej, sklepu, API, aplikacji Next.js, serwera poczty, bazy danych, crona i backupów jest często pierwszym narzędziem, które realnie zmniejsza chaos.

Największy plus? To darmowy monitoring self-hosted. Instalujesz go na własnym VPS-ie, w Dockerze, konfigurujesz monitory i sam decydujesz, gdzie trafiają alerty. Bez płacenia za każdy kolejny monitor. Bez limitu typu „5 usług w planie free”. Jest za to jeden warunek: musisz zadbać o samo narzędzie, jego kopię zapasową i sensowną konfigurację.

Dlaczego sama strona „działa u mnie” nie wystarczy?

Najgorszy monitoring to ręczne wejście na stronę raz dziennie. Daje złudzenie kontroli, ale nie łapie problemów, które bolą najbardziej: nocnych awarii, błędów po deployu, wygasających certyfikatów, padniętych cronów i usług działających tylko częściowo.

Typowy przykład: WordPress odpowiada, strona główna się ładuje, ale WooCommerce nie wysyła e-maili z zamówieniami. Albo API działa na /health, ale endpoint płatności zwraca 500. Albo VPS odpowiada na ping, lecz baza danych nie przyjmuje połączeń. Z zewnątrz wygląda to jak „serwer działa”. Z biznesowego punktu widzenia sprzedaż stoi.

Widzieliśmy też przypadek sklepu, który stracił około 30% dziennego obrotu, bo certyfikat Let’s Encrypt nie odnowił się automatycznie po zmianach w regułach Cloudflare. Sama aplikacja działała. Serwer działał. Tylko przeglądarki klientów pokazywały ostrzeżenie o SSL, więc część osób po prostu zamykała kartę. Gdyby wcześniej działał monitoring certyfikatu w Uptime Kuma, alert przyszedłby kilka dni przed wygaśnięciem, a nie po spadku sprzedaży.

Uptime Kuma pozwala rozbić monitoring na konkretne punkty:

• HTTP/HTTPS — czy adres strony lub API odpowiada poprawnym kodem, np. 200;
• keyword check — czy w odpowiedzi znajduje się oczekiwany tekst, np. „Dodaj do koszyka” albo "status":"ok";
• ping ICMP — czy host odpowiada na poziomie sieci;
• TCP port — czy działa konkretny port, np. 22, 25, 443, 5432, 3306, 6379;
• DNS — czy rekord domeny rozwiązuje się poprawnie;
• Push/heartbeat — czy cron, backup albo skrypt sam zgłosił, że zakończył pracę;
• SSL/TLS — czy certyfikat HTTPS jest poprawny i nie zbliża się do wygaśnięcia.

To ważne rozróżnienie. Monitoring strony nie powinien oznaczać jednego testu „czy domena odpowiada”. Dla małej firmy rozsądne minimum wygląda tak:

1. Strona główna przez HTTPS.
2. Panel logowania lub kluczowy endpoint.
3. API albo webhook, jeśli firma z niego korzysta.
4. Port bazy danych lub usługi wewnętrznej, jeżeli jest wystawiona tylko w prywatnej sieci.
5. Cron odpowiedzialny za faktury, synchronizację lub import danych.
6. Backup, który po zakończeniu wysyła heartbeat.
7. Certyfikat SSL dla domeny głównej i ważnych subdomen.

Największy priorytet mają te elementy, które bezpośrednio zatrzymują sprzedaż, kontakt z klientem albo proces operacyjny. Monitoring CPU, RAM i dysku też jest przydatny, ale nie zaczynałbym od niego, jeśli firma nie ma jeszcze alertu dla strony, checkoutu, certyfikatu SSL i backupu. Najpierw sprawdzamy to, co klient odczuwa od razu.

Trzeba też uczciwie powiedzieć, czego Uptime Kuma nie załatwia. Nie powie, dlaczego aplikacja zwolniła, jeśli nie zbudujesz pod to osobnych testów. Nie zastąpi logów błędów. Nie wykryje każdej awarii bazy danych, jeśli monitorujesz tylko stronę główną. Nie pomoże też, jeśli stoi na tym samym VPS-ie, który właśnie padł. Dlatego przy poważniejszych wdrożeniach Uptime Kuma najlepiej uruchomić na osobnym serwerze, nawet małym. Monitoring umieszczony na monitorowanym serwerze jest wygodny, ale ma oczywistą wadę: gdy VPS padnie w całości, razem z nim znika narzędzie alarmujące.

Jak monitorować HTTP, ping, porty, cron, backupy i SSL?

Najprostsza instalacja Uptime Kuma przez Docker wygląda tak:

docker volume create uptime-kuma

docker run -d \
  --restart=always \
  -p 3001:3001 \
  -v uptime-kuma:/app/data \
  --name uptime-kuma \
  louislam/uptime-kuma:1

Po uruchomieniu panel będzie dostępny pod adresem:

http://adres-serwera:3001

W naszych projektach zawsze konfigurujemy Uptime Kuma za reverse proxy i nie zostawiamy panelu administracyjnego wystawionego bezpośrednio na porcie 3001. Minimum produkcyjne to Nginx, Caddy, Traefik albo Nginx Proxy Manager, certyfikat HTTPS i osobna subdomena, np.:

https://status.twojadomena.pl

Samo mocne hasło to za mało. Panel monitoringu mówi dużo o infrastrukturze: domenach, portach, endpointach, awariach, nazwach usług. Dlatego lepsza konfiguracja bezpieczeństwa wygląda tak:

• HTTP Basic Authentication na poziomie Nginx lub Caddy przed ekranem logowania Uptime Kuma;
• ograniczenie dostępu po adresach IP, jeśli panel ma być tylko dla administratorów;
• Cloudflare Tunnel albo Tailscale, jeśli panel nie musi być publicznie widoczny;
• brak bezpośredniego wystawienia portu 3001 na świat;
• aktualizacje kontenera i regularna kopia danych.

To nie jest paranoja. Publicznie wystawione panele administracyjne trafiają do skanerów podatności, katalogów typu Shodan i automatycznych botów. Nawet jeśli Uptime Kuma nie ma w danym momencie krytycznej podatności, nie ma powodu, żeby ułatwiać komukolwiek mapowanie Twojej infrastruktury.

W Docker Compose konfiguracja może wyglądać tak:

services:
  uptime-kuma:
    image: louislam/uptime-kuma:1
    container_name: uptime-kuma
    restart: always
    ports:
      - "127.0.0.1:3001:3001"
    volumes:
      - uptime-kuma:/app/data

volumes:
  uptime-kuma:

Warto zwrócić uwagę na zapis:

ports:
  - "127.0.0.1:3001:3001"

To lepsze niż klasyczne "3001:3001", bo panel nasłuchuje lokalnie na serwerze, a nie na publicznym interfejsie. Ruch z internetu powinien przechodzić dopiero przez reverse proxy.

Uruchomienie:

docker compose up -d

Po pierwszym wejściu tworzysz konto administratora i przechodzisz do dodawania monitorów.

Jest jeszcze jeden techniczny detal, który łatwo pominąć: baza danych Uptime Kuma. Domyślnie narzędzie korzysta z SQLite. Przy monitoringu kilku, kilkunastu albo nawet kilkudziesięciu spokojnie ustawionych usług to bardzo dobre rozwiązanie: proste, szybkie, bez osobnego serwera bazy danych i bez dodatkowej administracji.

Problem zaczyna się wtedy, gdy ktoś próbuje zrobić z Uptime Kuma małe centrum monitoringu dla dziesiątek lub setek usług z bardzo krótkim interwałem. Przy ponad 50–100 monitorach odpytywanych np. co 10 sekund SQLite może stać się wąskim gardłem. Objawia się to błędami typu database is locked, opóźnieniami zapisu albo niestabilnym działaniem panelu. To nie znaczy, że SQLite jest „złe”. To znaczy, że ma granice.

Jeżeli planujesz większe wdrożenie, rozważ przejście na MariaDB w linii Uptime Kuma 2.x. Wtedy baza danych jest osobną usługą, lepiej znosi większą liczbę zapisów i łatwiej ją backupować narzędziami bazodanowymi. Do małego monitoringu nie komplikowałbym jednak architektury na start. Najpierw prosty Docker + SQLite, potem migracja dopiero wtedy, gdy liczba monitorów i interwały realnie zaczynają uzasadniać zmianę.

Monitoring HTTP/HTTPS ustawiasz dla strony, sklepu, API albo aplikacji. Dla strony firmowej wystarczy zwykle:

• typ monitora: HTTP(s);
• URL: https://twojadomena.pl;
• oczekiwany kod: najczęściej 200;
• interwał: 60 sekund albo 5 minut, zależnie od krytyczności;
• liczba ponowień: 2–3, żeby nie spamować alertami przy jednorazowym timeoutcie;
• timeout: np. 10–20 sekund.

Dla API lepiej nie sprawdzać losowego endpointu. Najlepszy jest prosty endpoint zdrowia, np.:

https://api.twojadomena.pl/health

Odpowiedź powinna być krótka i jednoznaczna:

{"status":"ok"}

Wtedy w Uptime Kuma można dodać nie tylko sprawdzanie kodu HTTP, ale też keyword monitoring — narzędzie uzna usługę za działającą dopiero wtedy, gdy w odpowiedzi znajdzie oczekiwaną frazę. To prosty sposób na uniknięcie fałszywego komfortu, gdy serwer zwraca stronę błędu z kodem 200.

Ping ma sens dla VPS-a, routera, hosta w sieci albo prostego sprawdzenia, czy maszyna odpowiada. Nie traktowałbym go jako głównego testu aplikacji. Serwer może odpowiadać na ping, a Nginx, PHP-FPM, Node.js albo baza danych mogą już leżeć. Ping jest dobrym testem pomocniczym, nie dowodem, że usługa działa.

Monitoring portów TCP przydaje się, gdy chcesz sprawdzić konkretną usługę:

• 22 — SSH;
• 80 — HTTP;
• 443 — HTTPS;
• 25, 465, 587 — poczta;
• 3306 — MySQL/MariaDB;
• 5432 — PostgreSQL jako monitorowana usługa;
• 6379 — Redis;
• 27017 — MongoDB.

Tu trzeba uważać. Nie każdy port powinien być publicznie dostępny. Jeżeli baza danych działa tylko w sieci prywatnej Dockera albo przez VPN, to dobrze. Nie otwieraj portu PostgreSQL do internetu tylko dlatego, że chcesz go monitorować z zewnątrz. W takim przypadku lepszy będzie monitor uruchomiony w tej samej prywatnej sieci albo test aplikacyjny, który sprawdza połączenie z bazą przez endpoint /health.

Certyfikat SSL warto monitorować osobno dla domeny głównej, subdomeny panelu, API i status page. To szczególnie ważne przy automatycznym odnawianiu Let’s Encrypt. Sam fakt, że certyfikat „powinien się odnowić”, nie znaczy, że się odnowi. Wystarczy zmiana DNS, problem z reverse proxy, błąd w certbocie albo blokada portu 80/443 i po sprawie.

Najlepsza praktyka: ustaw alert z wyprzedzeniem, nie dopiero w dniu wygaśnięcia. Przy certyfikatach nie ma sensu czekać do ostatniej chwili. Jeżeli ostrzeżenie przyjdzie 14 albo 7 dni wcześniej, jest czas na spokojną naprawę.

Najciekawszy element dla małych firm to Push/heartbeat. Normalny monitoring działa tak: Uptime Kuma pyta usługę „żyjesz?”. Push działa odwrotnie: to skrypt, cron albo backup zgłasza się do Uptime Kuma po zakończeniu pracy.

Przykład: masz backup bazy danych wykonywany codziennie o 02:00. W Uptime Kuma tworzysz monitor typu Push i dostajesz unikalny URL. Na końcu skryptu backupu dodajesz:

curl -fsS "https://status.twojadomena.pl/api/push/UNIKALNY_TOKEN?status=up&msg=backup-ok&ping="

Jeżeli backup nie wykona się w założonym czasie, Uptime Kuma oznaczy monitor jako niedziałający i wyśle alert. To dużo lepsze niż log, do którego nikt nie zagląda.

Dobrze ustawiony heartbeat powinien odpowiadać na trzy pytania:

• jak często zadanie ma się zgłaszać;
• po jakim czasie brak zgłoszenia oznacza problem;
• czy zgłoszenie ma następować tylko po sukcesie, czy także po błędzie.

Dla backupu dziennego nie ustawiaj tolerancji na 5 minut, jeśli zadanie czasem trwa 40 minut. Lepiej przyjąć margines: backup startuje o 02:00, zwykle kończy się do 02:20, więc alarm po 03:00 jest rozsądny. Dla crona uruchamianego co 5 minut margines może być znacznie krótszy.

Na końcu zostaje status page. To publiczna lub półpubliczna strona, na której pokazujesz stan usług: strona WWW, API, panel klienta, poczta, płatności, webhooki. Nie każda firma musi ją publikować. Dla małej strony usługowej status page bywa zbędny. Dla aplikacji SaaS, sklepu, hostingu albo systemu dla klientów — bardzo przydatny.

Status page nie powinien pokazywać wszystkiego. Nie publikuj nazw wewnętrznych baz danych, portów technicznych i prywatnych usług. Pokazuj to, co klient rozumie:

• Strona internetowa;
• Panel klienta;
• API;
• Płatności;
• Wysyłka e-mail;
• System zamówień.

Wewnętrzne monitory mogą być bardziej szczegółowe. Publiczna komunikacja powinna być czytelna, a nie zdradzać topologię infrastruktury.

Powiadomienia na Telegram, Discord, e-mail i Slack

Monitoring bez powiadomień jest ładnym dashboardem, a nie systemem alarmowym. Uptime Kuma obsługuje wiele kanałów, ale nie warto podpinać wszystkiego naraz. Szybko kończy się to hałasem, ignorowaniem alertów i sytuacją, w której prawdziwa awaria ginie między testowymi komunikatami.

Najprostszy układ dla małej firmy:

• Telegram — szybkie alerty techniczne dla właściciela lub administratora;
• Discord — kanał dla zespołu, np. #status albo #incydenty;
• e-mail — powiadomienia mniej pilne lub kopia dla osoby nietechnicznej;
• Slack — jeśli zespół i tak pracuje w Slacku.

Telegram sprawdza się bardzo dobrze, bo powiadomienie trudno przeoczyć. Konfiguracja wymaga bota i ID czatu. W praktyce wygląda to tak: tworzysz bota przez BotFather, pobierasz token, dodajesz bota do prywatnego czatu albo grupy, a następnie wpisujesz dane w Uptime Kuma. Po zapisaniu konfiguracji koniecznie użyj przycisku testowego. Bez testu nie zakładaj, że alerty działają.

Discord jest wygodny przez webhook. Tworzysz webhook w ustawieniach kanału, kopiujesz URL i wklejasz go w konfiguracji powiadomień. Dobry schemat to osobny kanał na monitoring, bez memów, bez rozmów i bez automatycznych komunikatów z innych narzędzi. Alert ma być widoczny.

E-mail jest najbardziej uniwersalny, ale ma wady. Może wpaść do spamu, może mieć opóźnienie, może nie zadziałać, jeśli awaria dotyczy tego samego serwera pocztowego. Jeżeli monitorujesz własny serwer mailowy i alerty wysyłasz przez ten sam serwer, tworzysz pętlę zależności. Przy poważniejszych usługach lepiej wysyłać alerty przez niezależnego dostawcę SMTP.

Slack działa podobnie jak Discord: webhook, kanał, test. W firmach, które siedzą cały dzień w Slacku, to najwygodniejsza ścieżka. Ale do krytycznych awarii nadal dodałbym drugi kanał — Telegram albo SMS przez zewnętrzną bramkę, jeśli proces naprawdę tego wymaga.

Kluczowe są progi alertów. Nie ustawiaj powiadomienia po jednym nieudanym sprawdzeniu, jeżeli monitor działa co 30 sekund. Internet ma chwilowe czkawki, DNS potrafi odpowiedzieć wolniej, a tani VPS może zgubić pojedynczy request. Dobre ustawienie dla strony firmowej to zwykle:

• interwał: 60 sekund;
• timeout: 10–20 sekund;
• ponowienia: 2 albo 3;
• alert dopiero po potwierdzonej awarii;
• osobny alert po powrocie usługi.

Dla krytycznego API można zejść niżej, ale trzeba liczyć się z większą liczbą fałszywych alarmów. Dla strony wizytówki interwał 5 minut jest często wystarczający. Nie ma sensu udawać centrum operacji sieciowych, jeśli realna reakcja człowieka i tak nastąpi po kilkunastu minutach.

W naszych wdrożeniach rozdzielamy alerty według ważności, bo inaczej monitoring szybko staje się kolejnym źródłem szumu. Awaria checkoutu, API płatności albo logowania trafia natychmiast do osoby odpowiedzialnej. Wygasający za 14 dni certyfikat SSL może trafić na e-mail i do zadania w systemie pracy. Brak heartbeat z backupu wymaga reakcji, ale zwykle nie musi budzić nikogo o 03:00, jeśli firma nie ma procedury nocnej obsługi incydentów.

Na koniec zostaje backup konfiguracji Uptime Kuma. To punkt, który wiele osób pomija, dopóki nie straci wszystkich monitorów. W Dockerze dane są trzymane w wolumenie /app/data. Jeżeli używasz nazwanego wolumenu uptime-kuma, zrób jego kopię.

Najprostszy backup wolumenu po zatrzymaniu kontenera:

docker stop uptime-kuma

docker run --rm \
  -v uptime-kuma:/data \
  -v $(pwd):/backup \
  alpine \
  tar czf /backup/uptime-kuma-data.tar.gz -C /data .

docker start uptime-kuma

To podejście ma jedną wadę: na chwilę wyłączasz monitoring. Ma też dużą zaletę: nie kopiujesz aktywnie zapisywanej bazy SQLite w trakcie pracy aplikacji.

Nie rób bezrefleksyjnie backupu przez zwykłe tar na działającym kontenerze, jeśli Uptime Kuma intensywnie zapisuje dane. Przy SQLite kopiowanie plików „w locie” może w skrajnych przypadkach dać uszkodzoną kopię bazy. Dla małego wdrożenia najprostsza bezpieczna procedura to zatrzymanie kontenera, wykonanie archiwum i ponowne uruchomienie. Przy większym wdrożeniu lepiej użyć mechanizmu backupu samej bazy, np. komendy .backup w SQLite albo standardowych narzędzi dla MariaDB.

Przykład logicznego backupu SQLite wymaga dostępu do pliku bazy wewnątrz danych Uptime Kuma i narzędzia sqlite3. Sama idea wygląda tak:

sqlite3 kuma.db ".backup '/backup/kuma-backup.db'"

Nie wklejaj tej komendy bez sprawdzenia ścieżek w swojej instalacji. W Dockerze lokalizacja pliku zależy od sposobu montowania danych. Najpierw sprawdź, gdzie faktycznie leży kuma.db, potem dopiero automatyzuj kopię.

Ten backup też warto monitorować heartbeatem. Brzmi zabawnie, ale jest praktyczne: narzędzie monitorujące powinno mieć własną kopię zapasową, a proces backupu powinien zgłaszać, że się wykonał.

Najrozsądniejsza kolejność wdrożenia jest prosta. Najpierw instalujesz Uptime Kuma na osobnym VPS-ie lub przynajmniej poza główną aplikacją. Potem chowasz panel za reverse proxy, dodajesz monitoring strony, API, SSL i backupu. Dopiero później porty, status page, okna serwisowe i bardziej szczegółowe testy. Nie zaczynaj od ozdobnego dashboardu. Zacznij od alertu, który faktycznie powie Ci, że klient nie może kupić, zalogować się albo wejść na stronę.

FAQ: Uptime Kuma w praktyce

Czy Uptime Kuma jest darmowe?
Tak. Uptime Kuma jest narzędziem open source i można je uruchomić na własnym serwerze bez opłat abonamentowych za monitory. Płacisz tylko za infrastrukturę, na której je utrzymujesz, np. VPS.

Czy Uptime Kuma zastępuje płatne narzędzia typu Pingdom, Better Stack albo StatusCake?
Dla małej firmy, WordPressa, sklepu, API albo kilku VPS-ów często wystarczy. Nie zastępuje jednak pełnego APM, analizy logów, rozbudowanych SLA, syntetycznych testów z wielu lokalizacji i zaawansowanego raportowania.

Czy Uptime Kuma powinno działać na tym samym VPS-ie co strona?
Może, ale to słabszy wariant. Jeśli VPS padnie całkowicie, monitoring też przestanie działać. Lepsza praktyka to osobny mały VPS, inny dostawca albo przynajmniej inna maszyna niż główna aplikacja.

Jak często ustawić sprawdzanie strony?
Dla ważnej strony lub sklepu zacznij od 60 sekund i 2–3 ponowień przed alertem. Dla prostej wizytówki wystarczy 5 minut. Bardzo krótki interwał bez ponowień zwykle daje więcej fałszywych alarmów niż pożytku.

Czy Uptime Kuma sprawdzi, że backup naprawdę się wykonał?
Tak, jeśli użyjesz monitora typu Push/heartbeat i dodasz wywołanie URL-a na końcu skryptu backupu. Samo sprawdzenie, że serwer działa, nie mówi nic o tym, czy kopia zapasowa powstała poprawnie.

Czy można monitorować cron?
Tak. Cron powinien po udanym zakończeniu wysłać heartbeat do Uptime Kuma. Jeśli nie zgłosi się w określonym czasie, dostaniesz alert.

Czy Uptime Kuma monitoruje certyfikaty SSL?
Tak. Można sprawdzać HTTPS i pilnować wygaśnięcia certyfikatu. To jeden z pierwszych monitorów, które warto dodać, szczególnie dla domen firmowych, API i paneli klienta.

Czy status page powinien być publiczny?
Nie zawsze. Publiczny status page ma sens dla aplikacji, SaaS, sklepu albo usługi dla klientów. Dla prywatnej infrastruktury lepiej ograniczyć go do zespołu i nie pokazywać nazw wewnętrznych usług.

Czy SQLite wystarczy dla Uptime Kuma?
Dla kilku lub kilkunastu monitorów — tak. Przy dziesiątkach usług, bardzo krótkich interwałach i częstych zapisach trzeba obserwować wydajność. Jeśli pojawiają się błędy database is locked, opóźnienia albo niestabilność panelu, czas rozważyć MariaDB w Uptime Kuma 2.x.

Czy panel Uptime Kuma można zostawić publicznie na porcie 3001?
Nie powinno się tego robić. Lepsza konfiguracja to reverse proxy, HTTPS, dodatkowa autoryzacja HTTP Basic Auth albo dostęp przez Cloudflare Tunnel/Tailscale. Panel monitoringu nie musi być widoczny dla całego internetu.

Co najpierw skonfigurować po instalacji?
Najpierw zabezpiecz dostęp do panelu. Potem dodaj monitor HTTPS dla strony, SSL, kluczowy endpoint API lub checkout, heartbeat backupu i powiadomienia. Dopiero później dodawaj porty, DNS, status page i mniej krytyczne usługi.

Jaki jest największy błąd przy wdrażaniu Uptime Kuma?
Dodanie kilkunastu monitorów bez przetestowania powiadomień i bez backupu konfiguracji. Monitoring ma alarmować i dać się odtworzyć po awarii. Bez tego jest tylko ładną tabelą w panelu.