Dlaczego monitoring HTTP(s) to fundament monitoringu webowego • Podstawy monitora HTTP(s) w Uptime Kuma • Metody HTTP — GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS • Custom headers — User-Agent, Accept, Authorization i inne • Request body dla POST, PUT i PATCH • Autentykacja — Basic, Bearer, OAuth2, NTLM, mTLS • Weryfikacja SSL/TLS i certyfikaty • Walidacja kodów statusu HTTP • Keyword monitoring — szukaj tekstu w odpowiedzi • JSON Query monitoring — walidacja pól JSON • Czas odpowiedzi — progi i alerty • Timeout i retry — eliminacja fałszywych alarmów • Monitoring za CDN — omijanie cache • Monitoring endpointów API z custom payloadami • Wskazówki dotyczące wydajności • Podsumowanie • Najczęściej zadawane pytania
Monitoring HTTP(s) to najbardziej uniwersalny i najczęściej stosowany typ monitorowania w świecie IT. Ponad 90% usług internetowych komunikuje się przez protokół HTTP lub HTTPS — od stron wizytówkowych po złożone API mikrousługowe, panele administracyjne, sklepy e-commerce i endpointy health check. Jeśli Twoja usługa jest dostępna przez przeglądarkę lub odpowiada na zapytania REST — monitoring HTTP(s) jest tym, od czego powinieneś zacząć.
Prosty ping (ICMP) powie Ci tylko, czy serwer odpowiada na poziomie sieciowym. Sprawdzenie portu TCP potwierdzi, że usługa nasłuchuje. Ale dopiero zapytanie HTTP pozwala zweryfikować, że aplikacja faktycznie działa poprawnie — zwraca właściwy kod statusu, serwuje poprawną treść i odpowiada w akceptowalnym czasie. To różnica między informacją „serwer jest online" a informacją „strona działa i klienci mogą z niej korzystać".
Uptime Kuma oferuje jeden z najbardziej rozbudowanych monitorów HTTP(s) wśród narzędzi open-source — wszystkie metody HTTP, custom headers, request body, pięć metod autentykacji, walidację SSL/TLS, keyword monitoring, JSON Query z JSONata, konfigurowalny timeout i retry. W tym przewodniku pokażemy krok po kroku, jak wykorzystać pełen potencjał tego monitora.
Dodanie monitora HTTP(s) w Uptime Kuma to proces, który zajmuje dosłownie kilka minut. Po zalogowaniu do panelu kliknij przycisk „Add New Monitor" w lewym górnym rogu dashboardu i wybierz typ HTTP(s), HTTP(s) - Keyword lub HTTP(s) - JSON Query z rozwijanej listy.
1.
Wprowadź pełny adres URL, włącznie z protokołem (https:// lub http://). Może to być strona internetowa (https://example.com), endpoint API (https://api.example.com/v1/health), panel administracyjny (https://admin.example.com/login) lub dowolny zasób HTTP. URL może zawierać ścieżkę, parametry query string i port niestandardowy (np. https://example.com:8443/status).
2.
Nadaj monitorowi opisową nazwę, np. „Strona główna — example.com" lub „API Health Check — produkcja". Ta nazwa wyświetla się na dashboardzie, w powiadomieniach i na stronach statusu. Dobrą praktyką jest stosowanie spójnej konwencji nazewnictwa, np. [Środowisko] Usługa — Opis.
3.
Określ, co ile sekund Uptime Kuma ma sprawdzać usługę. Domyślna wartość to 60 sekund. Minimalny interwał to 20 sekund — wystarczająco często, by wykryć awarię w mniej niż minutę. Dla krytycznych usług produkcyjnych zalecamy 20–60 sekund, dla mniej ważnych — 120–300 sekund. Pamiętaj, że niższy interwał oznacza więcej zapytań do monitorowanego serwera.
4.
Ustaw Max Retries (domyślnie 0, zalecane 1–3) i Retry Interval (interwał między próbami w sekundach). Po nieudanej próbie Uptime Kuma ponowi zapytanie zanim oznaczenie usługi jako DOWN. To kluczowe ustawienie eliminujące fałszywe alarmy spowodowane chwilowymi problemami sieciowymi lub krótkotrwałymi restartami serwera.
1.
W konfiguracji monitora rozwiń sekcję Authentication i wybierz metodę Basic.
2.
Wpisz Username i Password. Uptime Kuma automatycznie zakoduje je w Base64 i doda nagłówek Authorization: Basic dXNlcjpwYXNz.
Te cztery parametry wystarczą do uruchomienia podstawowego monitoringu HTTP(s). Ale prawdziwa moc Uptime Kuma ujawnia się w opcjach zaawansowanych — metodach HTTP, headerach, autentykacji i walidacji odpowiedzi.
Domyślnie Uptime Kuma wykonuje zapytanie GET, co jest odpowiednie dla większości scenariuszy — sprawdzania stron internetowych, endpointów health check i prostych API. Jednak w zaawansowanych przypadkach możesz potrzebować innej metody HTTP. Uptime Kuma obsługuje siedem metod:
| Metoda | Opis | Kiedy użyć w monitoringu |
|---|---|---|
| GET | Pobiera zasób. Domyślna metoda HTTP. Nie posiada body. | Strony www, endpointy /health, /status, publiczne API. |
| POST | Wysyła dane do serwera. Wymaga body (JSON, form data). | Monitoring API wymagających payloadu — np. GraphQL, API logowania, webhook test. |
| PUT | Zastępuje zasób w całości. Wymaga body. | Testowanie endpointów REST aktualizujących zasoby (np. upsert health check). |
| DELETE | Usuwa zasób. Body opcjonalne. | Rzadko stosowane w monitoringu. Przydatne do weryfikacji, że endpoint DELETE odpowiada poprawnie. |
| PATCH | Częściowa aktualizacja zasobu. Wymaga body. | Testowanie endpointów aktualizacji częściowej API REST. |
| HEAD | Jak GET, ale zwraca tylko nagłówki (bez body odpowiedzi). | Szybki test dostępności — mniejszy transfer. Sprawdzanie nagłówków cache, content-type, CORS. |
| OPTIONS | Zwraca dozwolone metody HTTP i nagłówki CORS. | Weryfikacja konfiguracji CORS, sprawdzanie jakie metody akceptuje endpoint. |
HEAD zamiast GET: Jeśli interesuje Cię tylko kod statusu i czas odpowiedzi — użyj HEAD. Mniejszy transfer, szybsza odpowiedź, mniejsze obciążenie serwera.
POST do testowania API GraphQL: API GraphQL przyjmują zapytania wyłącznie przez POST z body JSON. Skonfiguruj monitor POST z headerem Content-Type: application/json.
OPTIONS do weryfikacji CORS: Zapytanie OPTIONS (preflight) weryfikuje, że nagłówki CORS są poprawnie skonfigurowane — kluczowe dla aplikacji SPA.
Nagłówki HTTP (headers) to metadane dołączane do zapytania, które informują serwer o oczekiwaniach klienta, formacie danych, tożsamości i uprawnieniach. W Uptime Kuma możesz dodawać dowolne nagłówki HTTP do monitora — w formularzu konfiguracji znajdziesz pole „Custom Headers" przyjmujące obiekt JSON.
Nagłówki definiujesz jako obiekt JSON — klucze to nazwy nagłówków, wartości to ich treść:
{
"User-Agent": "UptimeKuma/2.1 MonitorBot",
"Accept": "application/json",
"Accept-Language": "pl-PL",
"X-Custom-Header": "monitoring-check"
}| Nagłówek | Opis | Przykład wartości |
|---|---|---|
| User-Agent | Identyfikuje klienta HTTP. Domyślnie Uptime Kuma wysyła własny User-Agent. | Mozilla/5.0 (compatible; UptimeKuma/2.1) |
| Accept | Określa akceptowane formaty odpowiedzi. | application/json, text/html, */* |
| Content-Type | Format body zapytania (dla POST/PUT/PATCH). | application/json, application/x-www-form-urlencoded |
| Authorization | Dane uwierzytelniające (token, klucz API). | Bearer eyJhbGciOiJI... |
| X-API-Key | Klucz API (alternatywa dla Authorization). | sk-abc123def456 |
| Cache-Control | Kontrola cache — ważne przy CDN. | no-cache, no-store |
| If-None-Match | Walidacja warunkowa — wymuszenie pełnej odpowiedzi. | * (wymuś odpowiedź 200 zamiast 304) |
| X-Forwarded-For | Symulacja IP źródłowego (testowanie geolokalizacji). | 203.0.113.50 |
Zmiana User-Agent: Niektóre WAF-y blokują zapytania z nietypowymi User-Agentami. Jeśli monitor zwraca 403 Forbidden, ustaw User-Agent na standardowy:
{
"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"
}Nagłówek autentykacji API: Wiele API wymaga klucza w nagłówku — przez Authorization lub dedykowany header:
{
"Authorization": "Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
"Accept": "application/json"
}Gdy wybierzesz metodę POST, PUT lub PATCH, Uptime Kuma udostępnia pole „Body", w którym możesz wpisać treść zapytania. Najczęściej jest to obiekt JSON, ale możesz wysłać również dane form-urlencoded, XML lub dowolny tekst — pod warunkiem ustawienia odpowiedniego nagłówka Content-Type.
{
"checks": ["database", "cache", "queue"],
"verbose": true
}W nagłówkach ustaw Content-Type: application/json i Accept: application/json.
{
"query": "{ systemHealth { status database cache } }",
"variables": {}
}W połączeniu z monitorem JSON Query możesz walidować, czy pole status w odpowiedzi ma wartość "healthy".
Dla endpointów wymagających application/x-www-form-urlencoded:
grant_type=client_credentials&client_id=my-app&client_secret=secret123Monitorowanie usług zabezpieczonych autentykacją to jedno z najczęstszych wyzwań w monitoringu HTTP. Uptime Kuma obsługuje pięć metod autentykacji natywnie — bez konieczności stosowania obejść czy zewnętrznych proxy. To więcej niż oferuje większość konkurencyjnych narzędzi, w tym wiele płatnych rozwiązań SaaS.
HTTP Basic Auth to najprostszy mechanizm autentykacji — login i hasło zakodowane w Base64 w nagłówku Authorization. Konfiguracja w Uptime Kuma:
Zastosowania: panele administracyjne zabezpieczone htpasswd (Apache/Nginx), prostsze API wewnętrzne, serwery monitoringu (Prometheus, Grafana), routery i urządzenia sieciowe z interfejsem webowym.
Bearer Token to popularna metoda autentykacji API, w której klient przesyła token (JWT, API key, personal access token) w nagłówku Authorization. W Uptime Kuma możesz go przekazać na dwa sposoby:
Sposób 1 — przez custom headers:
{
"Authorization": "Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.dozjgNryP4J3jVmNHl0w5N_XgL0n3I9PlFUP0THsR8U"
}Sposób 2 — przez sekcję Authentication: Wybierz metodę autentykacji w ustawieniach monitora i wklej token. Uptime Kuma automatycznie doda go jako nagłówek Authorization: Bearer .
Zastosowania: API REST z tokenami JWT, GitHub API (personal access tokens), Slack API, Stripe API, OpenAI API, Azure DevOps, Cloudflare API — praktycznie każde nowoczesne API komercyjne.
OAuth2 to standard autoryzacji używany przez Google, Microsoft, AWS, Salesforce. W scenariuszu Client Credentials (machine-to-machine) konfiguracja wymaga:
my-monitoring-app)https://auth.example.com/oauth2/token)read:health)Uptime Kuma automatycznie pobiera access token, cache'uje go i odnawia po wygaśnięciu. Działa z Keycloak, Auth0, Azure AD (Entra ID), Okta, AWS Cognito i innymi providerami OAuth2.
NTLM (NT LAN Manager) to protokół autentykacji Microsoftu, stosowany w IIS, SharePoint, Exchange i aplikacjach .NET. Uptime Kuma obsługuje NTLM natywnie — wybierz metodę NTLM, podaj Username (DOMAIN\user), Password i opcjonalnie Domain/Workstation.
Mutual TLS (mTLS) to najbezpieczniejsza metoda autentykacji HTTP — obie strony prezentują certyfikaty X.509 i wzajemnie się weryfikują. Konfiguracja w Uptime Kuma:
.pem / .crt).key)Zastosowania: architektura zero-trust, service mesh (Istio, Linkerd), API bankowe (PSD2), Kubernetes z wzajemną autentykacją podów, systemy IoT.
| Metoda autentykacji | Poziom bezpieczeństwa | Złożoność konfiguracji | Typowe zastosowanie |
|---|---|---|---|
| Basic Auth | Niski (wymaga HTTPS) | Minimalna | Panele admin, htpasswd, proste API |
| Bearer Token | Średni | Niska | API REST, JWT, klucze API |
| OAuth2 CC | Wysoki | Średnia | Enterprise API, cloud platforms |
| NTLM | Średni | Niska | Środowiska Windows/AD |
| mTLS | Najwyższy | Wysoka | Zero-trust, banking API, service mesh |
Każdy monitor HTTPS w Uptime Kuma automatycznie weryfikuje certyfikat SSL/TLS serwera. Jeśli certyfikat jest nieważny, wygasł, jest samopodpisany lub łańcuch certyfikatów jest niepełny — monitor zgłosi błąd. To domyślne i bezpieczne zachowanie, ale Uptime Kuma oferuje kilka opcji dostosowania.
W konfiguracji monitora znajdziesz przełącznik „Ignore TLS/SSL error" — po włączeniu Uptime Kuma zaakceptuje dowolny certyfikat, nawet wygasły, samopodpisany lub z nieprawidłowym CN/SAN. Ta opcja jest przydatna w następujących scenariuszach:
Uptime Kuma automatycznie odczytuje datę wygaśnięcia certyfikatu SSL dla każdego monitora HTTPS i wyświetla ją w panelu. Możesz skonfigurować alert przed wygaśnięciem certyfikatu — domyślne progi to 7, 14 lub 21 dni przed datą wygaśnięcia. Dzięki temu otrzymasz powiadomienie z wyprzedzeniem, nawet jeśli automatyczne odnawianie certyfikatu (Let's Encrypt, Certbot) zawiedzie.
Informacja o certyfikacie SSL (issuer, daty ważności, days remaining, fingerprint SHA-256) jest widoczna w panelu monitora i opcjonalnie na stronach statusu.
Jednym z najważniejszych aspektów monitoringu HTTP jest walidacja kodu statusu odpowiedzi. Uptime Kuma umożliwia precyzyjne określenie, jakie kody HTTP uznaje za poprawne (UP) — domyślnie akceptowane są kody z zakresu 200–299.
W polu „Accepted Status Codes" możesz wybrać:
200, 201, 204, 301, 401200-299, 200-399200-204, 301, 302| Scenariusz | Oczekiwany kod | Konfiguracja |
|---|---|---|
| Strona dostępna poprawnie | 200 OK | 200-299 (domyślne) |
| Przekierowanie na HTTPS | 301/302 | 200-299, 301, 302 |
| API zwraca No Content | 204 No Content | 200-204 |
| Strona logowania (wymaga auth) | 401 Unauthorized | 401 — monitorujesz, że strona logowania działa |
| Endpoint rate-limited | 429 Too Many Requests | 200-299, 429 — nie alarmujesz o rate limiting |
| Monitorowanie dowolnej odpowiedzi | Dowolny | 100-599 — tylko sprawdza, czy serwer odpowiada |
Domyślnie Uptime Kuma podąża za przekierowaniami (follow redirects), więc w większości przypadków otrzymasz finalny kod 200. Jeśli wyłączysz follow redirects — dodaj kody 3xx do listy akceptowanych.
Monitor HTTP(s) - Keyword rozszerza standardowy monitoring HTTP o sprawdzenie, czy odpowiedź serwera zawiera (lub nie zawiera) określony ciąg znaków. To potężna funkcja, która wykracza poza proste sprawdzenie kodu statusu — pozwala zweryfikować, że strona serwuje poprawną treść.
Istnieje wiele sytuacji, w których serwer zwraca kod 200 OK, ale treść strony jest niepoprawna:
Po wybraniu typu HTTP(s) - Keyword pojawią się dodatkowe pola:
Sprawdzenie, czy strona wyświetla właściwą treść:
Keyword: "Witamy na naszej stronie"
Keyword should: existWykrycie defacement lub podmienionej treści:
Keyword: "Hacked by"
Keyword should: not existWeryfikacja, że sklep wyświetla produkty:
Keyword: "Dodaj do koszyka"
Keyword should: existSprawdzenie, że strona nie jest w maintenance mode:
Keyword: "Przerwa techniczna"
Keyword should: not existMonitoring dostępności konkretnego produktu:
Keyword: "Dostępny"
Keyword should: existMonitor HTTP(s) - JSON Query to najbardziej zaawansowany wariant monitora HTTP w Uptime Kuma. Wyciąga konkretną wartość z odpowiedzi JSON za pomocą składni JSONata i porównuje ją z oczekiwaną wartością. Jeśli się zgadzają — monitor UP; jeśli nie — DOWN.
status, data.health, services[0].status)"ok", true, 200)Prosty klucz na najwyższym poziomie:
Odpowiedź API:
{
"status": "healthy",
"version": "2.1.0",
"uptime": 99.98
}Konfiguracja:
JSON Query: status
Expected Value: healthyZagnieżdżony klucz:
Odpowiedź API:
{
"data": {
"database": { "status": "ok", "latency_ms": 12 },
"cache": { "status": "ok", "latency_ms": 2 },
"queue": { "status": "degraded", "pending": 1503 }
}
}Konfiguracja:
JSON Query: data.database.status
Expected Value: okElement tablicy:
Odpowiedź API:
{
"checks": [
{ "name": "web", "alive": true },
{ "name": "db", "alive": true }
]
}Konfiguracja:
JSON Query: checks[0].alive
Expected Value: trueWyrażenie warunkowe JSONata:
JSONata obsługuje wyrażenia logiczne i matematyczne. Na przykład możesz sprawdzić, czy wszystkie serwisy w tablicy mają status „ok":
JSON Query: $count(checks[alive=false]) = 0
Expected Value: trueLub czy czas odpowiedzi bazy danych nie przekracza progu:
JSON Query: data.database.latency_ms < 100
Expected Value: truearray[condition]), agregację ($sum, $count, $average), wyrażenia warunkowe (condition ? 'yes' : 'no'), stringi ($contains, $match) i wiele więcej. Pełną dokumentację znajdziesz na docs.jsonata.org. Możesz testować wyrażenia interaktywnie na try.jsonata.org.
Uptime Kuma mierzy czas odpowiedzi (response time) w milisekundach i wyświetla go na wykresie w czasie rzeczywistym. Próg „Response Time Threshold" pozwala oznaczyć degradację — po przekroczeniu wartości na wykresie pojawia się żółty pasek zamiast zielonego (nie generuje alertu DOWN).
| Typ usługi | Próg ostrzegawczy | Próg krytyczny (rozważ alert) |
|---|---|---|
| Strona wizytówkowa | 1000 ms | 3000 ms |
| Sklep e-commerce | 500 ms | 2000 ms |
| API REST (health check) | 200 ms | 1000 ms |
| API wewnętrzne (LAN) | 50 ms | 200 ms |
| CDN / zasoby statyczne | 100 ms | 500 ms |
Czas odpowiedzi mierzony przez Uptime Kuma obejmuje pełny cykl zapytania HTTP (TCP + TLS + request + response), dlatego wartości mogą być wyższe niż samo przetwarzanie po stronie serwera.
Prawidłowa konfiguracja timeout i retry to klucz do eliminacji fałszywych alarmów (false positives).
Request Timeout (domyślnie 48 sekund) to maksymalny czas oczekiwania na odpowiedź. Zalecenia: strony i proste API — 10–15 s, ciężkie API z przetwarzaniem — 30–60 s, usługi w sieci LAN — 5–10 s.
Max Retries (domyślnie 0) to liczba dodatkowych prób po nieudanym zapytaniu. Retry Interval — czas między próbami. Zalecenia: usługi krytyczne — 2–3 retries, 20–60 s, standardowe — 1–2 retries, 60 s, szybka detekcja — 0–1 retry, 20 s (wyższe ryzyko false positive).
Uptime Kuma oferuje Resend Notification — ponowne wysłanie powiadomienia DOWN w ustalonych interwałach (np. co 5 minut), dopóki problem nie zostanie rozwiązany. Zabezpiecza przed przeoczeniem pierwszego alertu.
Monitorowanie stron za CDN (Cloudflare, Fastly, CloudFront) wymaga uwagi — CDN cache'uje odpowiedzi, więc Uptime Kuma może otrzymywać odpowiedź z cache nawet gdy origin jest niedostępny.
1. Nagłówek Cache-Control:
{
"Cache-Control": "no-cache, no-store, must-revalidate",
"Pragma": "no-cache"
}Te nagłówki instruują CDN, by nie serwował odpowiedzi z cache i przekazał zapytanie do serwera origin. Skuteczność zależy od konfiguracji CDN — niektóre konfiguracje ignorują te nagłówki klienta.
2. Unikalne parametry query string:
Dodaj losowy lub zmieniający się parametr do URL, np.:
https://example.com/health?_monitor=uptime-kuma&nocache=1CDN traktuje każdy unikalny URL jako oddzielny zasób i nie serwuje cache'owanej odpowiedzi. To najprostsze i najskuteczniejsze rozwiązanie.
3. Dedykowany endpoint health check:
Najlepsza praktyka — stwórz dedykowany endpoint (np. /health lub /api/status), który:
4. Monitorowanie serwera origin bezpośrednio:
Jeśli znasz adres IP serwera origin, możesz monitorować go bezpośrednio (z pominięciem CDN), dodając nagłówek Host:
URL: https://203.0.113.10/health
Custom Headers:
{
"Host": "example.com"
}Serwer origin odpowie tak, jakby zapytanie przyszło na example.com, ale CDN nie jest w ścieżce. Uwaga: wymaga to, by serwer origin akceptował połączenia bezpośrednie.
Dzięki obsłudze custom headers, body, autentykacji i JSON Query możesz monitorować praktycznie dowolne API. Oto typowe scenariusze:
| Parametr | Wartość |
|---|---|
| Typ monitora | HTTP(s) - JSON Query |
| URL | https://api.example.com/v1/health |
| Method | GET |
| Custom Headers | {"Authorization": "Bearer sk-abc123", "Accept": "application/json"} |
| JSON Query | status |
| Expected Value | ok |
| Accepted Status Codes | 200 |
| Parametr | Wartość |
|---|---|
| Typ monitora | HTTP(s) - JSON Query |
| URL | https://api.example.com/graphql |
| Method | POST |
| Custom Headers | {"Content-Type": "application/json", "Authorization": "Bearer token"} |
| Body | {"query": "{ __typename }"} |
| JSON Query | data.__typename |
| Expected Value | Query |
Zapytanie { __typename } to minimalne zapytanie GraphQL, które zawsze zwraca "Query" — idealne do sprawdzenia, czy serwer GraphQL odpowiada poprawnie, bez obciążania go ciężkimi operacjami.
| Parametr | Wartość |
|---|---|
| Typ monitora | HTTP(s) - JSON Query |
| URL | https://api.enterprise.com/v2/status |
| Method | GET |
| Authentication | OAuth2: CC |
| Client ID | monitoring-service |
| Client Secret | xxxxxxxxxxxxxxxx |
| Token URL | https://auth.enterprise.com/oauth2/token |
| Scopes | monitoring:read |
| JSON Query | services.$count([status != 'healthy']) = 0 |
| Expected Value | true |
Przy dziesiątkach lub setkach monitorów HTTP optymalizacja staje się kluczowa:
/health — lekki JSON ({"status":"ok"}) jest znacznie szybszy niż pełna strona główna z obrazami, CSS i JavaScript.Monitor HTTP(s) w Uptime Kuma to jedno z najpotężniejszych narzędzi monitoringu webowego w segmencie open-source — 7 metod HTTP, custom headers i body, 5 metod autentykacji (Basic, Bearer, OAuth2, NTLM, mTLS), weryfikacja SSL/TLS, keyword monitoring, JSON Query z JSONata, konfigurowalny timeout i retry. Wszystko to w przejrzystym interfejsie, bez pisania kodu.
Niezależnie od tego, czy monitorujesz prostą stronę wizytówkową, sklep e-commerce za Cloudflare, API REST z tokenem JWT, czy enterprise API zabezpieczone OAuth2 i mTLS — Uptime Kuma ma narzędzia do precyzyjnego i niezawodnego monitoringu.
Monitor HTTP(s) sprawdza tylko kod statusu i czas odpowiedzi — jeśli serwer zwraca akceptowany kod (np. 200), usługa jest UP. HTTP(s) Keyword dodatkowo przeszukuje treść odpowiedzi pod kątem określonego tekstu — usługa jest UP tylko wtedy, gdy kod statusu jest poprawny ORAZ tekst został znaleziony (lub nie znaleziony, w zależności od konfiguracji). HTTP(s) JSON Query parsuje odpowiedź jako JSON i sprawdza wartość konkretnego pola za pomocą wyrażenia JSONata — najdokładniejszy monitoring dla API zwracających dane strukturalne.
Tak, domyślnie Uptime Kuma podąża za przekierowaniami (follow redirects) — opcja Max Redirects domyślnie wynosi 10. Jeśli monitorujesz URL z przekierowaniem, monitor sprawdzi finalny URL. Aby monitorować sam fakt przekierowania, ustaw Max Redirects na 0 i dodaj kod 301 do akceptowanych kodów statusu.
Cloudflare cache'uje odpowiedzi, więc CDN może serwować wersję z cache mimo awarii origin. Rozwiązania: (1) nagłówek Cache-Control: no-cache, (2) dedykowany endpoint /health wyłączony z cache w Cache Rules, (3) monitoring origin bezpośrednio przez IP z nagłówkiem Host, (4) dwa monitory — CDN + origin.
Tak. Uptime Kuma natywnie obsługuje OAuth2 Client Credentials — podajesz Client ID, Client Secret, Token URL i opcjonalnie Scopes. Uptime Kuma automatycznie pobiera access token z serwera autoryzacji, cache'uje go i odnawia po wygaśnięciu. Token jest dołączany jako nagłówek Authorization: Bearer do każdego zapytania monitoringowego. Działa z Keycloak, Auth0, Azure AD (Entra ID), Okta, AWS Cognito i innymi providerami OAuth2.
Trzy kluczowe ustawienia: (1) Max Retries na 2–3, (2) Request Timeout na 10–15 sekund (nie domyślne 48), (3) Retry Interval na 20–30 sekund. Daje to ~75 sekund od pierwszej nieudanej próby do alertu — eliminuje chwilowe problemy sieciowe. Sprawdź też, czy monitor nie jest blokowany przez WAF lub rate limiting.
Tak. Uptime Kuma ma wbudowaną obsługę proxy — w konfiguracji monitora możesz wskazać proxy HTTP(s) lub SOCKS5. Przydatne w scenariuszach: monitorowanie usług w prywatnych sieciach (przez proxy z dostępem), testowanie z określonego IP, omijanie restrykcji sieciowych. Proxy definiujesz globalnie w ustawieniach (Settings → Proxies) i przypisujesz do wybranych monitorów.
Uptime Kuma używa biblioteki Axios (Node.js http/https), która komunikuje się przez HTTP/1.1. Nie stanowi to problemu — serwery obsługują obie wersje, a odpowiedzi monitoringowe (status code, nagłówki, body) są identyczne niezależnie od wersji protokołu.