Kody statusu HTTP wyjaśnione: co 200, 404, 502 znaczą dla monitoringu

W skrócie: Kod statusu HTTP to trzycyfrowa liczba, którą serwer odpowiada na każde żądanie. Grupa mówi kategorię: 2xx = OK, 3xx = przekierowanie, 4xx = błąd klienta, 5xx = błąd serwera. Z perspektywy uptime monitoringu interesują nas głównie anomalie 5xx i 4xx.

Kategorie odpowiedzi

• 1xx Informational - przejściowe odpowiedzi, klient zwykle nie zauważa.
• 2xx Success - żądanie przebiegło pomyślnie. 200 OK to default.
• 3xx Redirection - klient ma iść gdzie indziej. 301 permanent, 302 tymczasowy.
• 4xx Client errors - klient wysłał coś złego. 404, 401, 403, 429.
• 5xx Server errors - serwer zawiódł. 500, 502, 503, 504.

2xx: sukces

200 OK - standardowa odpowiedź OK. To jest stan "healthy", dla którego monitorujesz.

201 Created - typowo odpowiedź na POST, który stworzył nowy resource. Klienci API tego oczekują.

204 No Content - sukces, ale serwer nie ma co zwrócić. Endpointy DELETE często go używają.

206 Partial Content - serwer zwrócił tylko część (range request). Przy streamingu wideo lub resumable download.

3xx: przekierowanie

301 Moved Permanently - URL zmieniło się na stałe. Google przenosi SEO equity na nowy URL. Używać przy migracji domeny, przejściu z HTTP na HTTPS, przejściu na www/non-www.

302 Found / 307 Temporary Redirect - tymczasowe przekierowanie. Google nie przenosi rankingu. Używać przy A/B testowaniu, konserwacji lub gdy URL z czasem wróci.

308 Permanent Redirect - jak 301, ale zachowuje metodę HTTP (POST zostanie POST). 301 może klient zamienić na GET.

304 Not Modified - klient ma cache, serwer potwierdza, że treść się nie zmieniła. Oszczędza bandwidth.

Dla monitoringu: Przy kontroli odpowiedzi 3xx skonfiguruj, czy monitor ma śledzić przekierowanie (follow) czy uważać przekierowanie za błąd. Niektóre ataki DNS hijack przejawiają się jako nieoczekiwane 302.

4xx: błąd po stronie klienta

400 Bad Request - błąd składniowy w żądaniu. Malformed JSON, brakujący header, itd.

401 Unauthorized - brakujące lub złe credentials. Klient musi się autoryzować.

403 Forbidden - klient jest autoryzowany, ale nie ma uprawnienia. Uwaga: niektóre serwery zwracają 403 zamiast 401 ze względów bezpieczeństwa (nieujawnianie istnienia resourcu).

404 Not Found - URL nie istnieje. Dla monitoringu nie ma znaczenia, dla SEO tak (ucieka link equity).

405 Method Not Allowed - URL istnieje, ale nie akceptuje danej metody (np. POST do endpointu, który oczekuje GET).

408 Request Timeout - serwer czekał na żądanie zbyt długo i zamknął połączenie.

409 Conflict - żądanie jest w konflikcie z aktualnym stanem (np. update wersji, która już nie jest aktualna).

410 Gone - resource został trwale usunięty. Lepsze niż 404 dla Google (sygnał, że nie musi próbować reindeksować).

422 Unprocessable Entity - żądanie jest składniowo OK, ale zawiera semantycznie nieprawidłowe dane (failed validation).

429 Too Many Requests - rate limit. Klient musi zwolnić. Serwer typowo dodaje header Retry-After.

5xx: błąd po stronie serwera

500 Internal Server Error - ogólny błąd. Backend rzucił exception, której aplikacja nie złapała. Zawsze alarm dla monitoringu.

501 Not Implemented - serwer nie zna metody HTTP (np. stary serwer nie wspiera PATCH).

502 Bad Gateway - reverse proxy (nginx, Cloudflare) nie dostało odpowiedzi z serwera backend. Typowo backend padł lub timeoutował.

503 Service Unavailable - serwer jest przeciążony lub w konserwacji. Często z headerem Retry-After. To jest planowana odpowiedź, nie crash.

504 Gateway Timeout - reverse proxy czekało na backend dłużej niż timeout. Backend zwykle wciąż działa, tylko wolno.

520-525 Cloudflare errors - specyficzne dla Cloudflare. 520 = backend zwrócił coś nieczytelnego, 522 = backend nie odpowiedział (connection timeout), 524 = backend odpowiedział zbyt wolno (origin timeout).

Praktyczne zasady alertingu

• Alert natychmiast: 500, 502, 503 (jeśli nie naprawdę planowana konserwacja), 504, jakikolwiek timeout
• Alert przy powtórzeniu: jednorazowy 5xx może być race condition; alert jeśli ten sam endpoint pada 2× po sobie
• Śledzić trend wzrostowy: długoterminowy wzrost 4xx może oznaczać broken link, scraper attack lub rozbity frontend
• Ignorować dla alertingu: 200-399 w ramach oczekiwań (śledź response time zamiast kodu)

Kod statusu + response time = kompletny obraz

Śledzenie tylko kodu statusu nie wystarczy - serwer może zwracać 200, ale za 30 sekund, co z perspektywy klienta jest awarią. Jakościowy monitoring łączy:

1. Oczekiwany kod statusu (typowo 200)
2. Maksymalny response time (typowo 5-10 sekund)
3. Keyword match w treści (słowo kluczowe, które musi być w HTML)
4. SSL valid + nie przed końcem ważności

Wypadnięcie któregokolwiek = alert.

Monitoring z precyzyjną klasyfikacją błędów

ePulz.io rozróżnia kod statusu, response time, keyword match i stan SSL. Logi dla każdej kontroli.

Wypróbować na 7 dni →