W monitorowaniu dostępności krótka odpowiedź brzmi: odpowiedzi 2xx oznaczają, że strona działa, odpowiedzi 5xx – że leży, a wszystko pomiędzy zależy od tego, czego oczekujesz od danego adresu URL. Kod 301 jest w porządku, jeśli strona została celowo przeniesiona, 401 jest w porządku na endpoincie API wymagającym klucza, a 404 na stronie zamówienia to awaria. Dobrze ustawiony monitor sprawdza oczekiwany kod statusu, a nie tylko „cokolwiek poza błędem”.
Ta ściągawka omawia rodziny kodów statusu z perspektywy monitoringu: co oznacza każdy kod, czy powinien liczyć się jako awaria i jak skonfigurować sprawdzenia, by alarmowały tylko o prawdziwych problemach.
Pięć rodzin w skrócie
ZakresZnaczenieDla monitora1xxInformacyjne, żądanie trwa dalejRzadko spotykane; to nie jest ostateczna odpowiedź2xxSukcesZwykle działa3xxPrzekierowanie, szukaj gdzie indziejDziała albo nie, zależnie od zamierzenia4xxBłąd klienta, żądanie było niepoprawneZależy od endpointu5xxBłąd serwera, serwer zawiódłAwaria
Pierwsza cyfra mówi, kto odpowiada za problem. 4xx oznacza, że serwer uważa żądanie za błędne. 5xx oznacza, że serwer przyznaje się do porażki. Dla monitora, który co minutę wysyła to samo żądanie, nagłe 4xx zwykle i tak oznacza zmianę po stronie serwera: usunięto stronę, zmieniono uprawnienia albo zapora zaczęła blokować ruch.
1xx: informacyjne
Kody takie jak 100 Continue, 101 Switching Protocols i 103 Early Hints to odpowiedzi pośrednie. Klient widzi je przed ostateczną odpowiedzią albo wcale. Sprawdzenie monitoringu czeka na ostateczny kod statusu, więc tę rodzinę możesz pominąć. Jeśli sprawdzenie kiedykolwiek kończy się na 1xx, połączenie zostało przerwane w trakcie odpowiedzi, a to jest błąd.
2xx: sukces
KodNazwaUwagi dla monitoringu200OKStandardowa odpowiedź oznaczająca sukces201CreatedOczekiwany po żądaniu POST, które coś tworzy202AcceptedŻądanie w kolejce; praca odbędzie się później204No ContentSukces z pustą treścią; częsty przy DELETE i niektórych health checkach
Kod 200 nie gwarantuje, że strona działa. Wiele aplikacji przechwytuje własne błędy i wyświetla stronę błędu ze statusem 200: „Database connection failed”, pusty szablon, komunikat o konserwacji. Do ważnych sprawdzeń dodaj walidację treści: oczekuj słowa albo pola JSON, które pojawia się tylko wtedy, gdy strona naprawdę działa. Przy 204 nie ma treści do walidacji, więc sprawdzaj wyłącznie kod statusu.
3xx: przekierowania
KodNazwaTypowe zastosowanie301Moved PermanentlyZe starego URL na nowy, z HTTP na HTTPS302FoundTymczasowe przekierowanie, często na stronę logowania303See OtherPrzekierowanie po wysłaniu formularza metodą POST304Not ModifiedKopia w cache jest nadal aktualna; tylko po żądaniach warunkowych307Temporary RedirectJak 302, ale zachowuje metodę i treść308Permanent RedirectJak 301, ale zachowuje metodę i treść
Przekierowania a monitory
Narzędzia do monitoringu obsługują przekierowania na jeden z dwóch sposobów: podążają za nimi i raportują status strony docelowej albo zatrzymują się na pierwszej odpowiedzi i raportują 3xx. Wiedz, jak Twoje narzędzie zachowuje się przy każdym sprawdzeniu, bo oba podejścia mogą ukryć problemy:
Jeśli monitor podąża za przekierowaniami, strona, która nagle przekierowuje na stronę główną albo ekran logowania, nadal może zakończyć się kodem 200. Wyłapie to walidacja treści: strona główna nie zawiera słów ze strony zamówienia.
Jeśli monitor nie podąża za przekierowaniami, ustaw oczekiwany status na kod przekierowania, a docelowy URL sprawdzaj osobnym monitorem.
Najbezpieczniej monitorować bezpośrednio docelowy URL. Jeśli northwind.shop przekierowuje na www.northwind.shop, monitoruj wersję z www, a osobne sprawdzenie samego przekierowania dodaj tylko wtedy, gdy ma dla Ciebie znaczenie, na przykład dla starych linków z kampanii. Pętla przekierowań, w której dwa adresy wskazują na siebie nawzajem, kończy się przekroczeniem czasu albo błędem „too many redirects” i zawsze powinna liczyć się jako awaria.
4xx: błędy klienta
KodNazwaAwaria?400Bad RequestZwykle zepsute sprawdzenie albo zmienione API401UnauthorizedOczekiwany na chronionych endpointach bez danych uwierzytelniających403ForbiddenOczekiwany dla zablokowanych ścieżek; problem, jeśli pojawia się nagle404Not FoundAwaria dla każdego URL, który powinien istnieć405Method Not AllowedSprawdzenie używa złej metody albo zmieniła się trasa408Request TimeoutSerwer przestał czekać na żądanie410GoneUsunięte celowo429Too Many RequestsLimit żądań przekroczony
401 i 403 na chronionych endpointach
Niektóre endpointy powinny odrzucać anonimowe żądania. API administracyjne, które bez tokena zwraca 401, działa poprawnie. Możesz je monitorować na dwa sposoby:
Oczekuj odmowy. Ustaw oczekiwany status na 401. Sprawdzenie potwierdza, że serwer działa, a warstwa uwierzytelniania jest na miejscu. Jeśli kiedykolwiek zwróci 200 bez danych uwierzytelniających, to problem bezpieczeństwa wart alertu.
Wysyłaj dane uwierzytelniające. Dodaj do sprawdzenia nagłówek z kluczem API albo basic auth i oczekuj kodu 200 oraz właściwej treści. To testuje całą ścieżkę, łącznie z bazą danych za endpointem.
Druga opcja testuje więcej, więc stosuj ją dla wszystkiego, na czym polegają klienci. Do monitoringu używaj osobnego klucza tylko do odczytu, nigdy osobistego ani administracyjnego.
Nagłe 403 na publicznej stronie to zupełnie inna sprawa. Zwykle oznacza, że zapora, wtyczka bezpieczeństwa albo reguła CDN zaczęła blokować żądania, czasem tylko z niektórych krajów lub zakresów IP. Jeśli jedna lokalizacja monitoringu dostaje 403, a inna 200, najbardziej prawdopodobną przyczyną jest reguła geograficzna albo reguła IP.
429 Too Many Requests
Kod 429 oznacza, że serwer ogranicza liczbę żądań klienta. Dla monitoringu oznacza to jedno z dwojga: Twoje limity są zbyt restrykcyjne dla normalnego ruchu albo sam monitor trafia na limit, bo dzieli adres z innymi klientami. Sprawdź nagłówek Retry-After i konfigurację limitów. Jeśli prawdziwi użytkownicy dostają 429 przy normalnym obciążeniu, traktuj to jak awarię.
5xx: błędy serwera
KodNazwaCo zwykle oznacza500Internal Server ErrorAplikacja uległa awarii przy tym żądaniu501Not ImplementedSerwer nie obsługuje tej metody502Bad GatewayProxy dostało nieprawidłową odpowiedź od aplikacji za nim503Service UnavailablePrzeciążenie, konserwacja albo brak sprawnego backendu504Gateway TimeoutProxy zbyt długo czekało na aplikację
Każde 5xx traktuj jako awarię. Kody różnią się tym, gdzie najpierw szukać: 500 wskazuje na logi aplikacji, 502 na proces aplikacji, który uległ awarii albo się restartuje, 504 na wolne zapytania lub wywołania zewnętrzne, a 503 na brak zasobów albo konserwację. Nasz poradnik o błędzie 503 Service Unavailable szczegółowo omawia przyczyny i rozwiązania.
Niektóre CDN-y i proxy używają własnych kodów z zakresu 5xx, na przykład od 520 do 530, dla problemów między CDN a serwerem źródłowym. Nie należą do standardu HTTP, ale dla odwiedzającego znaczą to samo: strona nie działa.
Nie każda awaria ma kod statusu
Część najczęstszych awarii w ogóle nie zwraca kodu statusu:
Błąd DNS: domena się nie rozwiązuje, na przykład po wygaśnięciu rejestracji albo usunięciu rekordu.
Połączenie odrzucone lub zresetowane: nic nie nasłuchuje na porcie albo zapora zrywa połączenie.
Błędy TLS: wygasły lub niepasujący certyfikat zatrzymuje żądanie, zanim w ogóle dojdzie do HTTP.
Przekroczenie czasu: serwer przyjmuje połączenie, ale nie odpowiada na czas.
Dobry monitor zgłasza je jako błędy z konkretną przyczyną, więc alert mówi „certificate expired”, a nie tylko „down”. Dlatego też warto obok monitorów HTTP dodać sprawdzanie wygasania certyfikatów i domen.
Jak ustawić oczekiwany status w monitorze
Dla każdego monitorowanego adresu URL ustal, jak wygląda prawidłowa odpowiedź, i zapisz to jako konfigurację sprawdzenia:
Wybierz URL, który ma znaczenie. Docelowy adres po przekierowaniach, a nie skrócony link.
Ustaw metodę. GET dla stron, a dla API taką, jakiej wymaga endpoint.
Ustaw oczekiwany status. Zwykle 200. Użyj 201, 204, 301 albo 401, gdy to jest zamierzona odpowiedź.
W razie potrzeby dodaj dane uwierzytelniające. Nagłówki albo basic auth dla chronionych endpointów.
Dodaj walidację treści. Słowo na stronie albo pole w odpowiedzi JSON, które pojawia się tylko wtedy, gdy wszystko działa.
Ustaw limit czasu. Odpowiedź, która trwa 30 sekund, jest dla odwiedzającego porażką, nawet jeśli kończy się kodem 200.
Tak wygląda to dla endpointu health check w lumenanalytics.io, najpierw przetestowanego ręcznie za pomocą curl:
curl -sS -o /dev/null -w „%{http_code} %{time_total}s\n” \
-H „Authorization: Bearer $MONITOR_TOKEN” \
https://api.lumenanalytics.io/v1/health
Jeśli polecenie wypisze 200 i rozsądny czas, ta sama metoda, nagłówek i oczekiwany status trafiają do monitora. W Uptimecheck monitory dostępności i monitory API obsługują własną metodę, nagłówki (na przykład basic auth albo bearer token), treść żądania, sprawdzanie słów kluczowych i JSON, a sprawdzenie kończy się błędem, gdy kod statusu albo odpowiedź nie są takie, jakich oczekujesz. Więcej o projektowaniu samego endpointu znajdziesz w poradniku jak zbudować endpoint health check, a w checkliście monitorowania API – które endpointy objąć monitoringiem.
Szybka ściągawka: czy to awaria?
Awaria: każde 5xx, 404 na adresie, który powinien istnieć, przekroczenia czasu, błędy DNS i TLS, odrzucone połączenia.
Prawdopodobnie awaria: nagłe 403 albo 429 na publicznej stronie, 400 albo 405 przy sprawdzeniu, które wcześniej przechodziło.
Działa: kod statusu ustawiony jako oczekiwany, z treścią, którą walidujesz, w rozsądnym czasie.
Podsumowanie
Kody statusu to pierwsza rzecz, na którą patrzy monitor, i najszybszy sposób, by ustalić, gdzie leży problem. 5xx oznacza, że zawiódł serwer, 4xx – że zmieniło się coś w tym, co serwer akceptuje, a przy 3xx trzeba zdecydować, gdzie sprawdzenie ma się kończyć. Skonfiguruj każdy monitor z oczekiwanym statusem, waliduj treść ważnych stron i pozwól, by alert zawierał kod – wtedy osoba, która go odbierze, wie, od czego zacząć.
Uptimecheck sprawdza Twoje strony i API nawet co minutę i powiadamia Cię, gdy kod statusu albo odpowiedź nie są takie, jakich oczekujesz. Wypróbuj za darmo przez 14 dni, bez karty kredytowej.