Autor: Matt Connor 2026-07-15 · Zaktualizowano 2026-08-28

Uptime Kuma: konfiguracja monitoringu w Docker

Q: Jak skonfigurować powiadomienia przez Telegram lub e-mail?

Należy dodać kanał w sekcji Settings then Notifications, a następnie przypisać go do każdego monitora. W przypadku Telegrama należy utworzyć bota za pomocą @BotFather i odczytać chat.id z https://api.telegram.org/bot /getUpdates. Dla poczty e-mail należy użyć 465 dla SSL lub 587 dla STARTTLS, korzystając z hasła aplikacji, jeśli dostawca wymaga uwierzytelniania dwuskładnikowego. Przed rozpoczęciem korzystania z powiadomień należy nacisnąć Test i upewnić się, że wiadomość dotarła.

Q: Czy Uptime Kuma może monitorować zadania cron lub skrypty kopii zapasowych?

Tak, służy do tego monitor typu Push. Uptime Kuma generuje adres URL, który należy curl na końcu skryptu, aby wywołanie następowało tylko w przypadku powodzenia. Jeśli zadanie zakończy się niepowodzeniem lub maszyna będzie wyłączona, sygnał (heartbeat) nie dotrze, a użytkownik otrzyma powiadomienie po upływie zdefiniowanego interwału. Jest to jedyny niezawodny sposób na potwierdzenie wykonania zaplanowanego zadania, ponieważ zewnętrzna kontrola nie ma wglądu w jego wnętrze.

Wdrożenie Uptime Kuma w kontenerze Docker pozwala na monitoring stron, portów i DNS. Dowiedz się, jak poprawnie skonfigurować powiadomienia i uniknąć błędów przy monitoringu.

Co budujesz

Pojedynczy, niewielki kontener, który monitoruje inne serwery i strony internetowe z zewnątrz. Powiadamia on natychmiast po wykryciu braku odpowiedzi za pośrednictwem poczty elektronicznej, Telegram, Discord lub webhooka. Uptime Kuma to pojedynczy proces Node korzystający z bazy danych SQLite, dzięki czemu działa stabilnie przy 256-512 MB pamięci RAM. Narzędzie udostępnia pulpit nawigacyjny w czasie rzeczywistym, wykresy historii oraz publiczną stronę statusu. Instalacja wymaga dziesięcioliniowego pliku Compose. Kluczowe znaczenie ma jednak to, gdzie uruchamiasz to narzędzie oraz czy testowo sprawdziłeś działanie powiadomień. Monitor, którego skuteczności nie zweryfikowano, jest gorszy niż jego brak: daje złudne poczucie bezpieczeństwa, podczas gdy w rzeczywistości niczego nie nadzoruje.

Uruchom monitor w miejscu, do którego awaria nie dotrze

Ta decyzja decyduje o skuteczności całego rozwiązania, dlatego jest najważniejsza. Nie uruchamiaj Uptime Kuma na tym samym serwerze, który jest monitorowany. Jeśli monitor działa na serwerze, który nadzoruje, zdarzenie, którego chcesz uniknąć – awaria maszyny lub wyczerpanie pamięci RAM – wyłączy również monitor. W rezultacie nie otrzymasz żadnego powiadomienia: cisza ze strony martwego monitora jest nieodróżnialna od stanu „wszystko w porządku”. Istnieje również subtelniejsze zagrożenie, nawet gdy serwer działa: monitor skierowany na localhost współdzieli procesor z obciążeniem. Skok obciążenia powoduje przekroczenie czasu oczekiwania na odpowiedź (timeout), co oznacza cel jako down. Jest to fałszywy alarm, podczas gdy użytkownicy korzystają z usługi bez przeszkód.

Dlatego uruchom Uptime Kuma na innym VPS niż ten, który jest monitorowany. Najlepiej wybrać innego dostawcę lub region i łączyć się z usługami w taki sam sposób, jak robią to użytkownicy: przez publiczny internet, używając nazwy hosta. Wystarczy tania instancja; jeden mały VPS monitorujący może obsługiwać wszystkie Twoje serwery. Ta separacja jest kluczowa w przypadku zasobożernych aplikacji, ponieważ na przykład biblioteka zdjęć PhotoPrism lub Immich może obciążać procesor przez wiele godzin podczas indeksowania nowych plików. Monitor współdzielący ten sam sprzęt zgłosiłby awarię usługi, która jest po prostu zajęta. Aby wykryć awarię samego Uptime Kuma, skonfiguruj mechanizm push heartbeat w zadaniu cron na innym serwerze.

Wymagania wstępne i dobór zasobów

Świeża instalacja Ubuntu 24.04 na serwerze VPS z Docker Engine oraz wtyczką Compose v2, zainstalowanymi z oficjalnego repozytorium apt firmy Docker, a nie z pakietu docker.io dystrybucji, który jest przestarzały.
256 MB pamięci RAM wystarcza do obsługi kilku monitorów; 512 MB do 1 GB zapewnia komfortową pracę dla kilkudziesięciu monitorów wraz z reverse proxy, przy czym użycie procesora między sprawdzeniami jest bliskie zeru.
Domena oraz rekord DNS A (na przykład status.example.com wskazujący na adres IP serwera VPS), tylko jeśli wymagane jest TLS oraz publiczna strona statusu. W przypadku instancji prywatnej można pominąć DNS i korzystać z VPN lub tunelu SSH.
Dostęp do sieci wychodzącej dla powiadomień: SMTP do dostawcy poczty elektronicznej lub HTTPS do usług takich jak Telegram i Discord.

Plik Compose

Umieść go w /srv/uptime-kuma/compose.yaml.

services:
  uptime-kuma:
    image: louislam/uptime-kuma:2
    container_name: uptime-kuma
    restart: unless-stopped
    ports:
      - "127.0.0.1:3001:3001"
    volumes:
      - kuma-data:/app/data

volumes:
  kuma-data:

Uruchom usługę i obserwuj pierwsze logi:

sudo mkdir -p /srv/uptime-kuma
# save the file above as /srv/uptime-kuma/compose.yaml, then:
cd /srv/uptime-kuma && sudo docker compose up -d
sudo docker compose logs -f uptime-kuma

Poprawny start kończy się komunikatem Listening on 3001, po czym proces przechodzi w stan oczekiwania. Trzy elementy w tym pliku są zamierzone.

127.0.0.1:3001:3001, a nie 3001:3001. Docker publikuje porty za pomocą reguł DNAT, które są ewaluowane zanim ufw przetworzy pakiet, więc zwykłe 3001:3001 wystawia panel na publiczny dostęp niezależnie od konfiguracji firewalla. Powiązanie z interfejsem loopback zapewnia prywatność, pozostawiając dostępnym jedynie reverse proxy; instancja prywatna może pominąć proxy i łączyć się z 3001 poprzez własny serwer WireGuard VPN.

Wolumen nazwany w /app/data. Wszystkie dane pamiętane przez Uptime Kuma, czyli baza danych SQLite, monitory, ustawienia powiadomień oraz logotypy stron statusu, znajdują się w tym miejscu. Utrata tego katalogu oznacza powrót do pustego ekranu administratora; jest to jedyny element wymagający kopii zapasowej.

Obraz przypięty do głównej wersji, :2. Jest to aktualna stabilna linia; przed skopiowaniem sprawdź w Docker Hub najnowszą wersję główną i nigdy nie używaj zmiennych tagów typu latest, które są odradzane przez twórców projektu. Przeskok na nową wersję główną tego obrazu wiąże się z jednostronną migracją bazy danych, którą należy inicjować świadomie, a nie przez przypadek podczas rutynowego pobierania obrazu.

Uwaga: /app/data musi znajdować się na systemie plików obsługującym blokady plików POSIX. Lokalny wolumen Docker jest odpowiedni; na NFS baza danych SQLite ulega uszkodzeniu, co skutkuje błędami SQLITE_BUSY oraz database disk image is malformed, dlatego nigdy nie należy używać udziałów sieciowych.

Pierwsze uruchomienie: tworzenie konta administratora

Przejdź do instancji przez proxy pod adresem https://status.example.com lub za pomocą tunelu SSH: wykonaj ssh -L 3001:127.0.0.1:3001 user@your-vps i otwórz http://localhost:3001. Pierwsza strona to formularz konfiguracji nazwy użytkownika i hasła administratora; nie ma domyślnych danych logowania. Wybierz silne hasło: ten panel ma wgląd w wewnętrzne adresy i tokeny wszystkich monitorowanych zasobów. Jeśli zapomnisz hasła, zresetuj je z poziomu hosta, a nie przeglądarki:

sudo docker compose exec uptime-kuma npm run reset-password

Najpierw dodaj kanały powiadomień i przetestuj je

Skonfiguruj alerty przed dodaniem monitorów, aby móc przypisać kanał podczas tworzenia każdego z nich. Przejdź do Settings, następnie Notifications, a potem Setup Notification. Użyj przycisku Test dla każdego kanału, aby potwierdzić, że wiadomość dociera. Niesprawdzone powiadomienie to druga najczęstsza przyczyna cichej awarii konfiguracji.

Email (SMTP). Wypełnij host, port, szyfrowanie, nazwę użytkownika, hasło oraz adresy From i To. Dwie działające kombinacje to 465 z ustawieniem "Secure" na TLS/SSL lub 587 z użyciem STARTTLS. W przypadku Gmaila i większości dostawców z uwierzytelnianiem dwuskładnikowym należy wygenerować app password; zwykłe hasło do konta zwróci błąd Error: Invalid login: 535-5.7.8 Username and Password not accepted.

Telegram. Wyślij wiadomość do @BotFather, wyślij /newbot i skopiuj token bota. Aby uzyskać chat ID, wyślij wiadomość do nowego bota, otwórz https://api.telegram.org/bot<token>/getUpdates i odczytaj chat.id z pliku JSON. Bot, do którego nigdy nie wysłano wiadomości, ma pusty getUpdates i nie posiada miejsca docelowego dla powiadomień.

Discord. W kanale otwórz Edit Channel, następnie Integrations, Webhooks i New Webhook. Skopiuj adres URL i wklej go jako powiadomienie typu Discord.

Generic webhook. W przypadku innych rozwiązań, takich jak Slack incoming webhook, własny punkt końcowy lub automatyka domowa, typ Webhook wysyła metodą POST ładunek JSON na podany adres URL. Zintegrowany mechanizm Apprise obsługuje większość z ponad dziewięćdziesięciu innych usług z listy. Jeśli wolisz uniknąć pośrednictwa stron trzecich między awarią a telefonem, wybierz wbudowany typ ntfy i skieruj go na własny serwer ntfy, który przesyła powiadomienia na urządzenie przez kanał kontrolowany w całości przez Ciebie.

Dodawanie monitorów, jeden typ na raz

Kliknij Add New Monitor, wybierz typ i ustaw Friendly Name, Check Interval (60 sekund to rozsądna wartość), Retries (liczba kolejnych niepowodzeń przed oznaczeniem jako "down"; 2 lub 3 zapobiegają alarmowaniu przy pojedynczym zgubionym pakiecie) oraz powiadomienia, które mają zostać wywołane. Typy, z których będziesz korzystać:

HTTP(s). Pełny adres URL. Status "up" oznacza zaakceptowany kod odpowiedzi (domyślnie 200-299; rozszerz ten zakres w Accepted Status Codes, jeśli 301 lub 401 są dla Ciebie normalnymi wartościami). Podstawowe narzędzie do monitorowania stron WWW i API.
HTTP(s) - Keyword. To samo żądanie, ale status "up" wymaga dodatkowo obecności określonego ciągu znaków w treści odpowiedzi lub jego braku, jeśli zaznaczono Invert. Pozwala to wykryć sytuację, w której serwer zwraca 200 OK, ale wyświetla komunikat "Error establishing a database connection", co zwykły test HTTP uznałby za stan poprawny. Jest to również właściwy test dla interfejsów przeglądarkowych komunikujących się z oddzielnym backendem, takich jak skórka Halcyon dla serwera Jellyfin, której szkielet strony zwraca 200, nawet gdy serwer multimediów jest nieosiągalny.
TCP Port. Surowe połączenie TCP do hosta i portu, dla usług innych niż HTTP: SSH na 22, Postgres na 5432, serwer SMTP na 25 lub serwer gier.
Ping. Echo ICMP: tania metoda sprawdzania osiągalności i opóźnień. Wiele sieci i firewalli chmurowych odrzuca jednak pakiety ICMP, więc czerwony status monitora ping może oznaczać "host niedostępny" lub "dostawca blokuje ping"; potwierdź to za pomocą monitora TCP.
DNS. Rozwiązuje rekord (A, AAAA, MX, TXT itd.) za pomocą wskazanego resolvera i może weryfikować odpowiedź, co pozwala wcześnie wykryć awarię rejestratora lub usługi DNS.
Push. Monitor typu "inside-out", omówiony w następnej sekcji.

Monitorowanie zadania cron za pomocą monitora typu push (heartbeat)

Każdy z powyższych monitorów uzyskuje dostęp do usługi z zewnątrz. Monitor typu push działa odwrotnie: Uptime Kuma oczekuje na sygnał, a zadanie wysyła powiadomienie o swoim wykonaniu. Jest to jedyny rzetelny sposób nadzorowania kopii zapasowych lub zadań cron: test HTTP sprawdza jedynie dostępność adresu URL, natomiast tylko samo zadanie potwierdza poprawne zakończenie operacji.

Utwórz monitor typu Push. Uptime Kuma wygeneruje unikalny adres URL w formacie:

https://status.example.com/api/push/j8Xa2Kd9Qe?status=up&msg=OK&ping=

Ustaw Heartbeat Interval na wartość odpowiadającą częstotliwości uruchamiania zadania, dodając niewielki margines czasu. Następnie dodaj poniższą linię na końcu skryptu, aby wywołanie następowało wyłącznie w przypadku sukcesu:

#!/usr/bin/env bash
set -euo pipefail
# ... your backup or job runs here; set -e aborts on any failure ...
curl -fsS --retry 3 "https://status.example.com/api/push/j8Xa2Kd9Qe?status=up&msg=backup+ok&ping="

Jeśli zadanie zakończy się niepowodzeniem, set -e przerwie działanie przed wykonaniem polecenia curl; jeśli serwer będzie niedostępny, skrypt w ogóle się nie uruchomi. W obu przypadkach sygnał heartbeat przestanie docierać, a po upływie czasu określonego w interwale oraz liczbie ponownych prób, Uptime Kuma zmieni status monitora na down i wyśle powiadomienie. Traktuj token push jako poufny: każda osoba posiadająca ten klucz może sfałszować sygnał poprawnego działania.

Tworzenie publicznej strony statusu

Strona statusu to widok przeznaczony dla użytkowników: prezentuje stan usług oraz ich historię bez ujawniania panelu administracyjnego. Należy przejść do Status Pages, a następnie New Status Page, nadać nazwę oraz slug (ścieżkę publiczną, taką jak /status/main), przeciągnąć wybrane monitory do grup, na przykład "Websites" lub "APIs", dodać logo i krótki opis, a następnie zapisać zmiany. Stronę można również przypisać do własnej domeny, aby status.example.com obsługiwała ją bezpośrednio.

Dwie uwagi: należy dodawać tylko te monitory, które mają być publicznie widoczne, ponieważ strona statusu ujawnia istnienie usługi oraz jej aktualny stan. Panel administracyjny pozostaje zabezpieczony logowaniem, podczas gdy strona statusu jest z założenia publiczna i nie wymaga uwierzytelniania.

Umieszczenie za odwrotnym proxy z TLS i obsługa WebSocket

W przypadku instancji publicznej należy umieścić odwrotne proxy przed kontenerem powiązanym z interfejsem loopback, aby zapewnić obsługę TLS i nazwę hosta. Szczegół, który sprawia najwięcej problemów: interfejs Uptime Kuma to aplikacja Socket.IO działająca w czasie rzeczywistym, więc proxy musi obsługiwać upgrade połączenia do WebSocket. W przeciwnym razie strona załaduje się, ale nie nawiąże połączenia; pulpit nawigacyjny pozostanie w stanie "Connecting...", sygnały kontrolne (heartbeats) nie będą aktualizowane, a konsola przeglądarki wyświetli WebSocket connection to 'wss://.../socket.io/...' failed.

Zainstaluj nginx oraz certbot, a następnie utwórz plik vhost, który przekazuje ruch na port loopback. Na razie skonfiguruj port 80 i pozwól certbot dodać TLS później; wyzwania, harmonogram odnawiania oraz tryby awaryjne zostały opisane w wydawanie certyfikatów Let's Encrypt za pomocą certbot i nginx.

sudo apt install -y nginx certbot python3-certbot-nginx

Zapisz to jako /etc/nginx/sites-available/status.example.com; kluczowe znaczenie mają dwie linie dotyczące WebSocket:

server {
    listen 80;
    server_name status.example.com;

    location / {
        proxy_pass http://127.0.0.1:3001;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 3600s;
    }
}

Włącz witrynę, przetestuj konfigurację, a następnie pozwól certbot na nadpisanie bloku w celu nasłuchiwania na porcie 443, dodanie certyfikatu oraz przekierowania z HTTP na HTTPS:

sudo ln -s /etc/nginx/sites-available/status.example.com /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx
sudo certbot --nginx -d status.example.com

Para Upgrade oraz Connection "upgrade" stanowi o działaniu całości, a proxy_read_timeout 3600s zapobiega zrywaniu długotrwałego połączenia socket przez nginx; certbot skopiuje oba wpisy do wygenerowanego bloku 443. Jeśli używasz już kilku kontenerów za jednym proxy, kierowanie ruchu przez Traefik z automatycznym TLS realizuje to samo za pomocą etykiet kontenerów i domyślnie przekazuje upgrade'y WebSocket.

Nie stosuj uwierzytelniania Basic Auth dla całego vhost, ponieważ zablokuje to również publiczną stronę statusu oraz punkt końcowy /api/push. Pozostaw wbudowany mechanizm logowania Uptime Kuma, dodaj fail2ban monitorujący wielokrotne nieudane próby logowania, jeśli usługa jest wystawiona na świat, a jeśli pulpit nawigacyjny nie musi być publiczny, zrezygnuj z proxy i uzyskuj do niego dostęp przez VPN.

Monitorowanie wygaśnięcia certyfikatów w praktyce

Monitor HTTP(s) może ostrzegać o zbliżającym się wygaśnięciu certyfikatu TLS: należy zaznaczyć opcję Certificate Expiry Notification, a Uptime Kuma wyśle powiadomienie z wyprzedzeniem określonej liczby dni. Dwa błędy powodują błędne odczyty. Monitoruj usługę według nazwy hosta, a nie adresu IP, ponieważ żądanie bez SNI otrzyma domyślny certyfikat serwera, co skutkuje błędem Hostname/IP does not match certificate's altnames. Nie należy również zaznaczać opcji Ignore TLS/SSL Error w monitorze, od którego oczekuje się ostrzeżeń o wygaśnięciu: ten przełącznik służy do obsługi wewnętrznych hostów z certyfikatami typu self-signed (unable to verify the first certificate, DEPTH_ZERO_SELF_SIGNED_CERT), jednak powoduje on całkowite pominięcie sprawdzania certyfikatu przez Uptime Kuma, w tym daty jego ważności.

Kopie zapasowe: jeden katalog

Ponieważ wszystkie dane znajdują się w /app/data, kopia zapasowa jest kopią tego wolumenu wykonaną w czasie, gdy kontener jest zatrzymany. Dzięki temu plik SQLite pozostaje spójny:

cd /srv/uptime-kuma
sudo docker compose stop
sudo docker run --rm \
  -v uptime-kuma_kuma-data:/data \
  -v /var/backups/kuma:/backup \
  alpine tar czf /backup/kuma-$(date -u +%Y%m%dT%H%M%SZ).tgz -C /data .
sudo docker compose start

Najpierw należy potwierdzić rzeczywistą nazwę wolumenu za pomocą docker volume ls | grep kuma, ponieważ Compose dodaje do niej prefiks z nazwą katalogu projektu. Następnie należy skopiować archiwum tar poza serwer, ponieważ kopia wykonana na tym samym VPS jest jedynie duplikatem, a nie kopią zapasową. Przywracanie danych przebiega w odwrotnej kolejności: należy zatrzymać stos, wypakować dane do pustego wolumenu /app/data i uruchomić usługę.

Aktualizacje

Aktualizacje polegają na pobraniu nowego obrazu:

cd /srv/uptime-kuma
sudo docker compose pull
sudo docker compose up -d

Nowy kontener wykonuje migrację bazy danych przy pierwszym uruchomieniu; monitoruj docker compose logs -f. Wykonaj kopię zapasową zgodnie z powyższą instrukcją przed pobraniem obrazu i pozostań w obrębie tej samej głównej wersji: przejście z :1 na :2 jest migracją jednostronną, dlatego najpierw wykonaj kopię zapasową i sprawdź informacje o wydaniu (release notes).

Tryby awarii i odpowiadające im komunikaty

Fałszywy stan "down" w monitorze wskazującym na localhost. Monitor zmienia kolor na czerwony z komunikatem timeout of 48000ms exceeded lub connect ETIMEDOUT, mimo że usługa odpowiada z poziomu laptopa. Jeśli monitor celuje w ten sam host, na którym działa Uptime Kuma, przyczyną jest skok obciążenia CPU lub pamięci, który uniemożliwił wykonanie sprawdzenia, a nie awaria celu. Należy przenieść monitor na osobny VPS i wskazać publiczną nazwę hosta.

connect ECONNREFUSED 127.0.0.1:443 (lub dowolny port). Na danym porcie nic nie nasłuchuje: usługa jest wyłączona lub monitorowano localhost z wnętrza kontenera, gdzie 127.0.0.1 oznacza kontener, a nie serwer. Należy monitorować publiczną nazwę hosta, a nie adres pętli zwrotnej.

Invalid login: 535-5.7.8 Username and Password not accepted podczas testu poczty e-mail. Dane uwierzytelniające SMTP są błędne lub dostawca wymaga hasła specyficznego dla aplikacji, a otrzymuje hasło główne konta. Należy wygenerować hasło aplikacji i użyć go w konfiguracji.

connect ETIMEDOUT lub queryA ETIMEDOUT <host> podczas testu poczty e-mail. Błędny port lub blokada wychodzącego ruchu SMTP przez dostawcę. Należy potwierdzić, że 465 lub 587 odpowiada ustawieniom Secure/STARTTLS i przetestować połączenie z poziomu hosta za pomocą nc -vz smtp.example.com 587. Wielu dostawców blokuje wychodzący ruch 25, a niektórzy blokują porty pocztowe do czasu złożenia stosownego wniosku.

self signed certificate lub unable to verify the first certificate podczas testu poczty e-mail. Serwer SMTP przedstawia certyfikat, któremu Node nie ufa; należy naprawić certyfikat serwera pocztowego, zamiast ignorować błąd.

Panel sterowania zawieszony na "Connecting...", konsola pokazuje WebSocket connection ... failed. Reverse proxy nie obsługuje upgrade'u do WebSocket. Należy dodać nagłówki Upgrade oraz Connection "upgrade" w konfiguracji nginx lub użyć proxy, które przekazuje je domyślnie, takiego jak Traefik lub Caddy. Strona HTML ładuje się, ponieważ jest to standardowe żądanie HTTP GET; upgrade jest wymagany tylko dla aktywnego gniazda.

Monitor wygaśnięcia certyfikatu nie wysyła ostrzeżeń lub wysyła błędne. Zaznaczono opcję Ignore TLS/SSL Error, która wyłącza sprawdzanie certyfikatów, lub monitor celuje w adres IP i odczytuje niewłaściwy certyfikat z powodu braku SNI, co skutkuje Hostname/IP does not match certificate's altnames. Należy odznaczyć opcję ignorowania i monitorować według nazwy hosta.

SQLITE_BUSY lub database disk image is malformed w logach. Wolumen /app/data znajduje się na systemie plików bez poprawnej obsługi blokowania plików, zazwyczaj NFS; należy przenieść go na lokalny wolumen Docker i przywrócić dane z kopii zapasowej.

FAQ

Gdzie uruchomić monitor dostępności?

Na innym serwerze niż te, które są monitorowane, najlepiej u innego dostawcy lub w innym regionie. Monitor powinien łączyć się z nimi przez nazwę hosta w publicznym Internecie, tak samo jak robią to użytkownicy. Jeśli monitor współdzieli maszynę z monitorowanymi usługami, awaria serwera wyłączy również monitor, a przeciążony host może powodować fałszywe alarmy o niedostępności usług, które działają poprawnie. Niewielki, oddzielny VPS eliminuje oba te problemy.

Jak skonfigurować powiadomienia przez Telegram lub e-mail?

Należy dodać kanał w sekcji Settings then Notifications, a następnie przypisać go do każdego monitora. W przypadku Telegrama należy utworzyć bota za pomocą @BotFather i odczytać chat.id z https://api.telegram.org/bot<token>/getUpdates. Dla poczty e-mail należy użyć 465 dla SSL lub 587 dla STARTTLS, korzystając z hasła aplikacji, jeśli dostawca wymaga uwierzytelniania dwuskładnikowego. Przed rozpoczęciem korzystania z powiadomień należy nacisnąć Test i upewnić się, że wiadomość dotarła.

Czy Uptime Kuma może monitorować zadania cron lub skrypty kopii zapasowych?

Tak, służy do tego monitor typu Push. Uptime Kuma generuje adres URL, który należy curl na końcu skryptu, aby wywołanie następowało tylko w przypadku powodzenia. Jeśli zadanie zakończy się niepowodzeniem lub maszyna będzie wyłączona, sygnał (heartbeat) nie dotrze, a użytkownik otrzyma powiadomienie po upływie zdefiniowanego interwału. Jest to jedyny niezawodny sposób na potwierdzenie wykonania zaplanowanego zadania, ponieważ zewnętrzna kontrola nie ma wglądu w jego wnętrze.

Uptime Kuma czy Zabbix – co wybrać?

Uptime Kuma odpowiada na pytanie „czy usługa działa z zewnątrz i czy wysłano powiadomienie” w dziesięć minut, przy minimalnym zużyciu zasobów, oferując dodatkowo stronę statusu. Narzędzie to nie zbiera szczegółowych metryk, takich jak trendy użycia CPU, pamięci, dysku czy progi dla całej floty serwerów. Do takich celów służy pełnoprawny serwer monitorujący Zabbix, który jest cięższym rozwiązaniem opartym na agentach; wielu administratorów korzysta z obu tych narzędzi jednocześnie. Nadal nie wiesz, co wybrać? Nasze zestawienie usług do samodzielnego hostowania w 2026 roku przedstawia monitorowanie w szerszym kontekście.

#uptime-kuma#monitoring #docker #self-hosting#status-page