HTTP 200 nie oznacza, że aplikacja działa. Co naprawdę powinien sprawdzać monitoring?

1. co kilka minut wysyła żądanie HTTP,
2. serwer odpowiada,
3. system sprawdza kod odpowiedzi,
4. jeśli otrzyma 200 OK, uznaje stronę za działającą.

Problem w tym, że:

HTTP 200 oznacza tylko, że serwer zwrócił odpowiedź HTTP z kodem 200. Nie oznacza, że aplikacja rzeczywiście działa poprawnie.

Sklep może zwracać 200 OK, mimo że nie można dodać produktu do koszyka.

Panel klienta może działać, ale logowanie może kończyć się błędem.

Strona może się otwierać, ale jej API może odpowiadać przez 15 sekund.

Checkout może się wyświetlać, ale każda próba płatności może kończyć się błędem.

Monitoring pokazujący wyłącznie zielone „UP” może w każdym z tych przypadków uznać, że wszystko działa.

Uptime i poprawne działanie aplikacji to dwie różne rzeczy

Załóżmy, że monitorujemy:

https://example.com

System wykonuje żądanie:

GET /

Serwer odpowiada:

HTTP/1.1 200 OK

Z punktu widzenia prostego uptime monitora wszystko jest w porządku.

Ale użytkownik nie korzysta ze strony internetowej poprzez sprawdzanie jej kodu HTTP.

Użytkownik:

• otwiera stronę,
• klika,
• wyszukuje,
• loguje się,
• wysyła formularze,
• dodaje produkty do koszyka,
• wykonuje płatności,
• korzysta z API.

Dlatego pytanie:

„Czy serwer odpowiada?”

jest tylko pierwszym poziomem monitoringu.

Znacznie ważniejsze pytanie brzmi:

„Czy użytkownik może wykonać to, po co przyszedł na stronę?”

Przypadek 1: strona zwraca 200, ale wyświetla komunikat o błędzie

Wyobraźmy sobie aplikację, w której wystąpił problem z bazą danych.

Backend przechwytuje wyjątek i zamiast zwrócić HTTP 500, renderuje własną stronę błędu.

Odpowiedź może wyglądać tak:

HTTP/1.1 200 OK
Content-Type: text/html

a jej zawartość:

<h1>Something went wrong</h1>
<p>Please try again later.</p>

Dla użytkownika aplikacja nie działa.

Dla prostego monitora:

200 OK

czyli wszystko jest w porządku.

Dlatego dobry monitoring HTTP nie powinien ograniczać się wyłącznie do statusu odpowiedzi.

W określonych przypadkach warto sprawdzać również jej zawartość.

Na przykład oczekiwać, że strona zawiera konkretny element lub tekst charakterystyczny dla poprawnie załadowanej aplikacji.

Przypadek 2: homepage działa, checkout nie

To jeden z najważniejszych problemów w monitoringu sklepów internetowych.

Monitor sprawdza:

GET /

i otrzymuje:

200 OK

Tymczasem:

/cart

działa, ale:

/checkout

kończy się błędem.

Albo jeszcze gorzej - checkout również zwraca 200, ale JavaScript odpowiedzialny za wybór metody płatności przestał działać.

Z perspektywy infrastruktury sklep jest dostępny.

Z perspektywy biznesowej sklep może być praktycznie wyłączony.

Jeżeli użytkownik nie może zapłacić, to fakt, że strona główna działa, ma niewielkie znaczenie.

Dlatego monitoring powinien obejmować najważniejsze ścieżki biznesowe, a nie tylko homepage.

W sklepie mogą to być:

• strona główna,
• karta produktu,
• wyszukiwarka,
• koszyk,
• checkout,
• endpointy płatności,
• API odpowiedzialne za stany magazynowe.

W aplikacji SaaS:

• logowanie,
• rejestracja,
• dashboard,
• najważniejsza funkcja aplikacji,
• API,
• kolejki lub zadania cykliczne.

Przypadek 3: aplikacja działa, ale jest tak wolna, że praktycznie nie działa

Kolejny problem pojawia się wtedy, gdy odpowiedź wygląda tak:

HTTP 200
Response time: 12.8 s

Czy aplikacja działa?

Technicznie tak.

Czy użytkownik uzna ją za działającą poprawnie?

Niekoniecznie.

Monitoring powinien więc analizować nie tylko dostępność, ale również czas odpowiedzi.

Warto przy tym uważać na pojedyncze skoki.

Jeżeli typowy czas odpowiedzi wynosi 300 ms, a jeden request trwał 900 ms, nie musi to oznaczać awarii.

Jeżeli jednak przez ostatnie 20 minut odpowiedzi wzrosły:

300 ms → 450 ms → 800 ms → 1.4 s → 2.8 s

to mamy znacznie ciekawszy sygnał.

Aplikacja jeszcze działa, ale jej kondycja wyraźnie się pogarsza.

To często najlepszy moment na reakcję - zanim nastąpi pełna awaria.

Przypadek 4: frontend działa, ale API nie

Współczesne aplikacje często składają się z wielu niezależnych elementów.

Przykładowo:

Frontend
   ↓
API
   ↓
Database
   ↓
Redis
   ↓
Queue
   ↓
External services

Samo otwarcie frontendu może nie uruchamiać wszystkich tych zależności.

Aplikacja Next.js może poprawnie wyrenderować stronę, podczas gdy backend API zwraca błędy.

Podobnie panel administracyjny może się otwierać, mimo że kolejka przestała przetwarzać zadania.

Dlatego monitoring samego publicznego URL-a nie daje pełnego obrazu kondycji aplikacji.

Przypadek 5: błędy występują tylko u części użytkowników

Jeszcze trudniejsze są awarie częściowe.

Przykładowo problem może występować tylko:

• na urządzeniach mobilnych,
• w konkretnej przeglądarce,
• dla użytkowników z określonego kraju,
• po zalogowaniu,
• dla konkretnej metody płatności,
• dla jednego endpointu API.

Z punktu widzenia zwykłego uptime monitora aplikacja może przez cały czas wyglądać na całkowicie zdrową.

To pokazuje, dlaczego monitoring zewnętrzny warto łączyć z monitoringiem błędów wewnątrz aplikacji.

Uptime i error monitoring odpowiadają na inne pytania

Monitoring uptime odpowiada przede wszystkim na pytanie:

„Czy z zewnątrz można połączyć się z usługą?”

Monitoring błędów odpowiada natomiast na pytanie:

„Czy podczas działania aplikacji występują błędy?”

To dwie różne perspektywy.

Załóżmy, że aplikacja obsłużyła w ciągu godziny:

100 000 requestów

i 2% z nich zakończyło się błędem aplikacyjnym.

To daje:

2 000 błędnych requestów

Jednocześnie homepage podczas każdego sprawdzenia monitora mógł zwracać:

200 OK

Uptime:

100%

Nie oznacza to jednak, że aplikacja działała bezproblemowo.

Monitoring powinien działać warstwowo

Zamiast próbować odpowiedzieć jednym wskaźnikiem na pytanie „czy wszystko działa?”, lepiej obserwować kilka niezależnych warstw.

Warstwa 1: dostępność

Czy serwer odpowiada?

Sprawdzamy między innymi:

• kod HTTP,
• timeout,
• problemy DNS,
• problemy z połączeniem,
• przekierowania.

Warstwa 2: czas odpowiedzi

Jak szybko odpowiada aplikacja?

Interesuje nas nie tylko aktualna wartość, ale również jej zmiana w czasie.

Nagłe pogorszenie wydajności może być pierwszym sygnałem problemu.

Warstwa 3: certyfikat SSL

Czy certyfikat:

• jest prawidłowy,
• nie wygasł,
• nie wygaśnie za kilka dni?

Awaria SSL jest szczególnie niepotrzebna, ponieważ zazwyczaj można wykryć ją długo przed tym, zanim stanie się problemem.

Warstwa 4: zawartość odpowiedzi

Czy serwer zwrócił to, czego oczekujemy?

Sam status 200 może nie wystarczyć.

Warstwa 5: błędy aplikacji

Czy backend generuje wyjątki?

Warto obserwować między innymi:

• rodzaj błędu,
• stack trace,
• endpoint,
• środowisko,
• wersję aplikacji,
• moment pierwszego i ostatniego wystąpienia,
• częstotliwość występowania.

Warstwa 6: wydajność strony

Aplikacja może odpowiadać szybko na poziomie HTTP, a mimo to działać wolno w przeglądarce.

Dlatego warto obserwować również wydajność frontendu i Core Web Vitals.

Warstwa 7: proces biznesowy

Najwyższy poziom monitoringu odpowiada na pytanie:

„Czy użytkownik rzeczywiście może wykonać najważniejszą czynność?”

Dla sklepu będzie to zakup.

Dla SaaS może to być logowanie i wykonanie głównej operacji.

Dla serwisu leadowego - wysłanie formularza.

Najbardziej niebezpieczne awarie nie zawsze oznaczają całkowity downtime

Pełna awaria jest paradoksalnie łatwa do wykrycia.

Jeżeli serwer przestaje odpowiadać i zaczyna zwracać:

502 Bad Gateway

monitoring szybko zauważy problem.

Znacznie trudniejsze są awarie typu:

strona działa, ale coś ważnego przestało działać.

To właśnie takie problemy potrafią pozostawać niezauważone przez wiele godzin.

Sklep działa, ale nie przyjmuje zamówień.

Formularz działa wizualnie, ale nie wysyła wiadomości.

Aplikacja działa, ale część użytkowników nie może się zalogować.

API działa, ale jeden krytyczny endpoint zwraca błędy.

Dlatego skuteczny monitoring nie powinien sprowadzać całego stanu aplikacji do jednej zielonej lub czerwonej kontrolki.

Co więc oznacza „aplikacja działa”?

Nie istnieje jedna uniwersalna odpowiedź.

Dobrze monitorowana aplikacja powinna być obserwowana z kilku perspektyw jednocześnie:

• czy odpowiada,
• czy odpowiada wystarczająco szybko,
• czy zwraca prawidłową zawartość,
• czy nie generuje nietypowej liczby błędów,
• czy jej certyfikat jest prawidłowy,
• czy frontend działa wydajnie,
• czy najważniejsze funkcje biznesowe są dostępne.

Dopiero połączenie tych informacji daje rzeczywisty obraz kondycji aplikacji.

HTTP 200 jest ważnym sygnałem. Ale jest tylko jednym z nich.