Jest sobota, 8:47 o poranku. Telefon wibruje. To nie alert z Twojego systemu – to wiadomość od klienta: „Strona nie działa, próbuję od godziny”. Od godziny. A Ty dowiadujesz się o tym właśnie teraz, od kogoś z zewnątrz.
Jeśli kiedykolwiek byłeś po tej stronie tej rozmowy, wiesz, że problemem nie była sama awaria. Awarie się zdarzają – to wpisane w branżę. Problemem było to, że ostatni dowiedziałeś się o niej Ty, czyli osoba, która mogła ją naprawić najszybciej.
„Przecież mam health check”
To najczęstsza odpowiedź, jaką słyszy się po takiej historii. I owszem – wewnętrzny health check to dobra praktyka. Endpoint zwracający status aplikacji, sprawdzenie połączenia z bazą, kontrola puli wątków. To wszystko ma sens.
Problem polega na tym, że health check odpowiada na pytanie „czy aplikacja myśli, że działa?” – a nie „czy użytkownik jest w stanie z niej skorzystać?”. To dwie różne rzeczy. Aplikacja może raportować pełną gotowość, podczas gdy:
- wygasł certyfikat SSL i przeglądarka pokazuje użytkownikowi czerwony ekran ostrzeżenia,
- serwer odpowiada, ale po 12 sekundach – czyli z perspektywy człowieka „nie działa”,
- padł reverse proxy albo load balancer stojący przed Twoją aplikacją,
- wygasła domena, zmienił się rekord DNS, „coś” w sieci między użytkownikiem a serwerem,
- deployment przeszedł, health check świeci na zielono, ale kluczowa ścieżka biznesowa zwraca błąd.
Health check patrzy na system od środka. Użytkownik patrzy z zewnątrz. Te dwie perspektywy potrafią się rozjechać – i właśnie w tej luce mieszka większość „cichych” awarii.
Monitoring działa w warstwach
Dobra obserwowalność systemu to nie jedno narzędzie, tylko kilka warstw, z których każda widzi co innego:
Logi i metryki mówią Ci, co się dzieje wewnątrz aplikacji – to nieoceniona pomoc przy diagnozie, gdy już wiesz, że jest problem.
Wewnętrzne health checki pilnują kondycji pojedynczych komponentów i często sterują tym, czy ruch w ogóle trafia do danej instancji.
Monitoring zewnętrzny (uptime) robi jedną rzecz, której żadna z powyższych warstw nie zrobi: odpytuje Twój serwis z zewnątrz, dokładnie tak, jak zrobiłby to użytkownik. Z innej sieci, innego regionu, bez dostępu do Twoich wewnętrznych metryk – po prostu „czy to się otwiera i odpowiada poprawnie?”.
Pierwsze dwie warstwy odpowiadają na pytanie dlaczego coś nie działa. Trzecia odpowiada na pytanie czy w ogóle działa – i to ona dzwoni do Ciebie pierwsza.
Co realnie daje monitoring zewnętrzny
Dobre narzędzie do monitoringu dostępności to nie tylko „ping co minutę”. W praktyce zdejmuje z Ciebie kilka konkretnych zmartwień:
- Wykrycie awarii z perspektywy użytkownika, a nie serwera – sprawdzenie z wielu lokalizacji eliminuje fałszywe alarmy wynikające z lokalnych problemów sieciowych.
- Alert, który faktycznie dotrze – e-mail, SMS, powiadomienie na telefon, integracja z komunikatorem zespołowym. Tak, żebyś dowiedział się Ty, a nie klient.
- Pilnowanie tego, o czym się zapomina – monitoring certyfikatu SSL i terminu ważności domeny. To klasyk: nikt o tym nie myśli, dopóki nie jest za późno.
- Czas odpowiedzi w czasie – żebyś zobaczył, że serwis „muli”, zanim zacznie zwracać błędy.
- Status page – publiczna strona statusu, która sama informuje użytkowników o awarii i odciąża Ciebie oraz support.
Ile naprawdę kosztuje cisza
Łatwo machnąć ręką: „przecież awarie zdarzają się rzadko”. Tyle że koszt awarii to nie sama awaria – to czas, przez który nikt o niej nie wiedział. Każda minuta niewykrytej niedostępności to utracone transakcje, sfrustrowani użytkownicy i nadszarpnięte zaufanie, którego nie odbudujesz jednym przeprosinowym mailem. Różnica między „wykryliśmy i naprawiliśmy w 4 minuty” a „klient zgłosił po godzinie” to często różnica między incydentem, którego nikt nie zauważył, a tym, który trafia do rozmów o odejściu klienta.
Jak zacząć bez wielkiego projektu
Najlepsze w monitoringu zewnętrznym jest to, że nie wymaga przebudowy aplikacji ani wpinania się w kod – niezależnie od tego, czy chodzi o stronę, czy o monitoring API. Wystarczy:
- Podać adres, który ma być sprawdzany (strona, endpoint API, krytyczna ścieżka).
- Ustawić częstotliwość sprawdzeń i kanały alertów.
- Dodać monitoring certyfikatu i domeny.
- (Opcjonalnie) włączyć publiczną stronę statusu.
Cały setup to kwestia kilku minut – a efekt jest taki, że następnym razem to Ty będziesz tą osobą, która wysyła wiadomość „mamy chwilowy problem, już działamy”, zamiast tą, która ją odbiera.
Co wybrać? Od darmowych narzędzi po rozliczenie w modelu pay as you go
Dobra wiadomość: nie musisz od razu sięgać po drogie, rozbudowane rozwiązanie. Jeśli Twój projekt jest niewielki – blog, portfolio, jedna aplikacja – w zupełności wystarczy darmowy monitoring stron internetowych. Sporo usług ma bezpłatny plan, który sprawdza dostępność co kilka minut i wysyła alert mailem. Na start to często wszystko, czego potrzeba.
Gdy projekt rośnie, wybór płatnych dostawców jest dziś ogromny – od prostych „pingerów” po rozbudowane platformy obserwowalności. Z popularnych, sprawdzonych nazw warto znać przede wszystkim UptimeRobot, a obok niego choćby Pingdom czy Better Stack.
Nowością na tym rynku jest jednak inny model rozliczeń: nie sztywny abonament, lecz płatność według rzeczywistego zużycia. Zamiast z góry kupować pakiet, z którego wykorzystasz połowę, płacisz tylko za to, ile faktycznie monitorujesz. Daje to znacznie lepszą kontrolę nad kosztami i – zwłaszcza przy mniejszej lub nieregularnej skali – z reguły wychodzi po prostu taniej niż gotowy plan.
W tym modelu działa m.in. polski uMonitor, który rozlicza monitoring właśnie w formule pay as you go – płacisz za rzeczywiste zużycie, bez sztywnego abonamentu (z darmowym planem na start).
Podsumowanie
Awarie są nieuniknione – różnicę robi to, jak szybko się o nich dowiesz. Wewnętrzne health checki i metryki mówią, co dzieje się w aplikacji, ale dopiero spojrzenie z zewnątrz pokazuje, czy użytkownik faktycznie może z niej skorzystać. Dobór narzędzia to kwestia skali: dla małych projektów w zupełności wystarczy darmowy plan, a większe mają dziś w czym wybierać – od klasycznych abonamentów po rozliczenie za zużycie. Najważniejsze jednak nie jest to, które narzędzie wybierzesz, lecz to, że w ogóle je masz. Bo jedyna rzecz gorsza od awarii to awaria, o której nie wiesz.
