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

Kategorie odpowiedzi

• 1xx Informational - przejściowe odpowiedzi, klient zwykle ich nie zauważa.
• 2xx Success - żądanie przebiegło pomyślnie. 200 OK to wartość domyślna.
• 3xx Redirection - klient ma iść gdzie indziej. 301 trwale, 302 tymczasowo.
• 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 stan "healthy", który monitorujesz.

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

204 No Content - sukces, ale serwer nie ma czego zwrócić. Często używają go endpointy DELETE.

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żywaj przy migracji domeny, przejściu z HTTP na HTTPS lub przejściu na www/non-www.

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

308 Permanent Redirect - jak 301, ale zachowuje metodę HTTP (POST zostaje POST). Przy 301 klient może zmienić metodę 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 traktować je jako błąd. Niektóre ataki DNS hijack objawiają 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ę uwierzytelnić.

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

404 Not Found - URL nie istnieje. Dla uptime monitoringu śledzonych stron 404 to alert (strona zniknęła); przypadkowe 404 od obcych odwiedzających to raczej problem SEO (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. Dla Google lepsze niż 404 (sygnał, by nie 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 - błąd ogólny. Backend rzucił exception, której aplikacja nie złapała. Zawsze alarm dla monitoringu.

501 Not Implemented - serwer nie zna danej 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 odpowiedź planowana, nie crash.

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

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 to nie jest naprawdę planowana konserwacja), 504, jakikolwiek timeout
• Alert przy powtórzeniu: jednorazowy 5xx może być race condition; alert uruchom, jeśli ten sam endpoint pada 2x z rzędu
• Śledzić trend wzrostowy: długoterminowy wzrost 4xx może oznaczać broken link, scraper attack lub zepsuty frontend
• Ignorować dla alertingu: 200-399 w granicach oczekiwań (zamiast kodu śledź czas odpowiedzi)

Kod statusu + czas odpowiedzi = kompletny obraz

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

1. Oczekiwany kod statusu (typowo 200)
2. Maksymalny czas odpowiedzi (typowo 5-10 sekund)
3. Dopasowanie słowa kluczowego w treści (słowo kluczowe, które musi być w HTML)
4. SSL ważny i nie blisko końca ważności

Wypadnięcie któregokolwiek = alert.

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

ePulz.io rozróżnia kod statusu, czas odpowiedzi, dopasowanie słowa kluczowego i stan SSL. Dostępne są szczegółowe logi dla każdej kontroli.

Wypróbować na 7 dni →