Monitoring strony internetowej — kto dowie się pierwszy, Wy czy klient

Monitoring strony odpowiada na jedno pytanie: kto dowie się o awarii pierwszy — Wy czy klient. Wszystko inne, od wyboru narzędzia po częstotliwość sprawdzania, jest odpowiedzią na to pytanie albo odciąga od niego uwagę.

Najprostszy monitor pyta serwer o stronę co kilka minut i sprawdza, czy odpowiedź ma kod 200, czyli „w porządku". Jeśli ma — uznaje, że strona działa. Tyle że kod 200 mówi wyłącznie, że serwer coś odesłał, a nie że odesłał to, co powinien.

Mamy na to dowód na własnej stronie. Sprawdziliśmy, co nasz serwis odpowiada na adres, który nie istnieje. Odsyła stronę z tytułem „404 — nie znaleziono strony" — i kodem 200. Człowiek widzi błąd. Monitor sprawdzający tylko kod widzi stronę, która działa. Google nazywa to w swojej dokumentacji soft 404 i ostrzega, że takie strony błędów mogą trafić do indeksu.

U nas to świadomy kompromis, nie przeoczenie. Nasza strona jest wysyłana do przeglądarki strumieniowo, kawałkami, żeby treść pojawiała się szybciej — a dokumentacja Next.js wyjaśnia, że serwer musi wtedy potwierdzić „200", zanim wie, czy adres istnieje. W zamian dopisuje do strony błędu znacznik noindex, więc Google jej nie zaindeksuje. Wyszukiwarce to wystarcza. Monitorowi — nie, bo monitor znacznika nie czyta. I to jest właśnie powód, dla którego pytanie „czy strona odpowiada" to za mało.

Co właściwie sprawdza monitor

Słowo „monitoring" obejmuje cztery różne sprawdzenia. Różnią się tym, o co pytają stronę — a więc tym, które awarie są w stanie zobaczyć.

Kod odpowiedzi. Monitor pobiera adres i sprawdza, czy serwer odpowiedział kodem 200. Wykrywa serwer, który nie odpowiada wcale, i błędy serwera. Nie wykrywa niczego, co serwer poda z kodem 200 — strony błędu, pustej strony, strony, na której zniknęła połowa treści. To sprawdzenie jest w każdym narzędziu i zwykle ustawia się je jako pierwsze, więc warto wiedzieć, czego nie widzi.

Treść na stronie. Monitor pobiera stronę i szuka na niej konkretnego tekstu — nazwy firmy w stopce, nagłówka, numeru telefonu. Jeśli go nie ma, podnosi alarm, nawet przy kodzie 200. To jedno ustawienie więcej, a zamyka największą lukę pierwszego sprawdzenia. Tekst warto wybrać taki, który nie zmienia się przy każdej aktualizacji treści, i taki, którego nie ma na stronie błędu.

Cała ścieżka. Monitor wykonuje to, co robi klient: otwiera formularz, wypełnia go, wysyła, sprawdza potwierdzenie — albo dodaje produkt do koszyka i dochodzi do płatności. To jedyne sprawdzenie, które widzi, że strona „działa", a firma nie dostaje zapytań. Jest droższe, trudniejsze w utrzymaniu i przy każdej zmianie formularza trzeba je poprawić, więc ma sens tam, gdzie ta jedna ścieżka jest źródłem przychodu.

Daty wygaśnięcia. Certyfikat i domena nie psują się stopniowo — przestają działać w konkretnym dniu, który znacie z góry. Monitor, który sprawdza tylko bieżący stan, zauważy problem dopiero w dniu awarii. Monitor, który sprawdza datę, ostrzeże tydzień wcześniej.

Dla typowej strony firmowej rozsądny zestaw to kod i treść na stronie głównej i na podstronie kontaktowej, data certyfikatu i data domeny. Pełna ścieżka — dla sklepu i dla formularza, od którego zależy sprzedaż.

Czy strona działa — kto się dowie pierwszy

Pytanie „czy strona działa" ma sens tylko razem z drugim: jak szybko ktoś się o tym dowie i co zrobi. Monitor sprawdzający co pięć minut w najgorszym razie zauważy awarię pięć minut po jej początku. Tyle że to jest najkrótszy odcinek całej historii.

Umowa, która gwarantuje 99,9% dostępności, dopuszcza 44 minuty przestoju w miesiącu — rachunek rozkładamy przy obsłudze strony. Na tym tle widać proporcje. Przejście z pięciu minut na jedną oszczędza cztery minuty. Obietnica „reagujemy w ciągu godziny" sama zużywa więcej, niż cały miesięczny budżet dopuszcza. O tym, ile trwa awaria, decyduje nie częstotliwość sprawdzania, tylko to, co się dzieje po alercie.

Dlatego pierwsze pytanie przy ustawianiu monitoringu brzmi nie „jak często sprawdzać", tylko „kto dostanie powiadomienie i czy może coś z nim zrobić". Częstotliwość ma znaczenie przy sklepie z dużym ruchem, gdzie każda minuta to zamówienia. Przy stronie firmowej pięć minut wystarczy, jeśli po drugiej stronie jest ktoś, kto zareaguje.

Jest jeszcze jeden powód, żeby mieć własny monitoring, nawet jeśli stroną opiekuje się firma zewnętrzna ze swoim. Narzędzia do monitoringu dostępności — po angielsku uptime monitoring — prowadzą raport: jaki procent czasu strona odpowiadała w danym miesiącu, ile było przerw i jak długo trwały. To jest Wasz niezależny pomiar umowy. Jeśli wykonawca obiecuje 99,9%, a Wasz monitor pokazuje w miesiącu dwie godziny przerw, macie liczbę do rozmowy, a nie wrażenie. Bez własnego pomiaru jedynym źródłem wiedzy o tym, czy umowa została dotrzymana, jest raport strony, która ją miała dotrzymać.

Darmowy monitoring stron www — UptimeRobot i inne

Do sprawdzania kodu odpowiedzi i treści nie trzeba płacić. Nazwę jednego z nich, UptimeRobot, wpisuje się w polską wyszukiwarkę ponad tysiąc razy w miesiącu (w dwóch pisowniach) — i to dobry punkt odniesienia, co dostaje się za darmo, a gdzie zaczyna się płatny plan.

Według cennika UptimeRobot plan darmowy obejmuje 50 monitorów sprawdzanych co 5 minut, z powiadomieniami e-mailem. Najtańszy płatny plan sprawdza co 60 sekund i kosztuje 9 euro miesięcznie przy płatności rocznej. Jedno zastrzeżenie: w sekcji pytań na tej samej stronie dostawca opisuje plan darmowy jako przeznaczony do „basic personal monitoring". Przed użyciem go dla strony firmowej warto przeczytać aktualny regulamin, bo warunki darmowych planów zmieniają się częściej niż cenniki.

Alternatywą jest monitoring uruchomiony u siebie — na przykład Uptime Kuma, otwarte oprogramowanie na licencji MIT. Nie ma limitu monitorów ani interwału, ale wymaga serwera, który ktoś utrzymuje. I tu jest pułapka, która dotyczy każdego monitoringu, nie tylko samodzielnego: monitor nie może stać na tym samym serwerze co strona. Jeśli padnie serwer, padnie razem z nim to, co miało o tym powiadomić.

Z tego samego powodu monitoring powinien sprawdzać stronę z zewnątrz, z internetu, tak jak robi to klient. Serwer, który sam sprawdza siebie, może raportować, że wszystko działa, podczas gdy z zewnątrz nie da się do niego dotrzeć — bo zawiódł DNS, certyfikat albo sieć po drodze.

Kto dostaje alert

Alert, którego nikt nie przeczyta, to wpis w dzienniku. Większość źle działających systemów monitoringu nie zawodzi na etapie wykrycia, tylko na etapie powiadomienia: alerty idą na skrzynkę, którą ktoś przestał czytać, albo do osoby, która nie ma dostępu do serwera.

Trzy ustalenia, które zamieniają monitoring w coś, co działa:

• Imiennie, kto dostaje alert — i w jakich godzinach. Jeśli stroną opiekuje się firma zewnętrzna, alert powinien trafiać i do niej, i do kogoś u Was. Wtedy wiecie o awarii niezależnie od tego, czy wykonawca się odezwie, i możecie sprawdzić, jak szybko zareagował.
• Co ta osoba może zrobić. Powiadomienie o trzeciej w nocy do właściciela firmy bez dostępu do serwera daje tylko tyle, że będzie wiedział rano. Ścieżka eskalacji — kto dostaje alert, kto wie, jak naprawić, kto decyduje o przywróceniu kopii — powinna być spisana, zanim się przyda.
• Potwierdzenie przed alarmem. Pojedyncze nieudane sprawdzenie bywa chwilowym problemem sieci po stronie monitora. Narzędzia pozwalają podnieść alarm dopiero po potwierdzeniu — powtórnym sprawdzeniu albo sprawdzeniu z innej lokalizacji. Bez tego po kilku fałszywych alarmach ludzie przestają reagować na prawdziwe, a to jest gorsze niż brak monitoringu, bo daje poczucie, że ktoś pilnuje.

Warto też ustalić, co jest dziennikiem, a co alarmem. Wydłużony czas odpowiedzi serwera to informacja do przejrzenia raz w tygodniu. Strona, która nie odpowiada — powód, żeby kogoś obudzić. Kto dostaje jedno i drugie na telefon, po tygodniu wyłączy powiadomienia.

Strona nie działa — pierwsze piętnaście minut

Alert przyszedł albo zadzwonił klient: strona nie działa. Zanim ktokolwiek zacznie naprawiać, warto w kilka minut ustalić, co dokładnie nie działa i od kiedy, bo od tego zależy, kogo wołać. Kolejność, która oszczędza najwięcej czasu:

1. Czy nie działa tylko u Was. Otwórzcie stronę na telefonie, na danych komórkowych, nie w firmowej sieci. Jeśli tam działa, problem leży po stronie Waszego łącza albo przeglądarki, nie serwera. Monitor sprawdzający z zewnątrz rozstrzyga to od razu — jeśli go nie ma, telefon jest najszybszym zamiennikiem.
2. Co dokładnie widać. Brak odpowiedzi, błąd 500, ostrzeżenie o certyfikacie, pusta biała strona, strona dostawcy hostingu zamiast Waszej — każdy z tych obrazów wskazuje inną przyczynę. Ostrzeżenie o certyfikacie to certyfikat. Strona rejestratora albo komunikat o wygaśnięciu — domena. Biała strona albo 500 — zwykle aplikacja: wtyczka, motyw, ostatnia zmiana.
3. Co zmieniło się ostatnio. Aktualizacja, nowa wtyczka, zmiana na serwerze, przeniesienie DNS. Większość awarii ma przyczynę w czymś, co zrobiono w ciągu ostatniej doby, i odkręcenie tej jednej zmiany jest szybsze niż szukanie przyczyny od zera.
4. Czy to nie dostawca. Hostingi i dostawcy DNS publikują strony ze statusem swoich usług. Jeśli awaria jest po ich stronie, Wasza praca kończy się na zgłoszeniu i informacji dla klientów.
5. Czy jest do czego wrócić. Jeśli przyczyny nie widać, a strona ma wrócić, pytanie brzmi: z której kopii i ile danych od tej chwili się straci — to decyzja właściciela, nie wykonawcy, i dobrze, żeby znał odpowiedź, zanim przyjdzie mu ją podjąć; jak ustawić kopie, żeby ta decyzja była prosta, opisujemy przy kopiach zapasowych.

Te pięć kroków warto mieć zapisane w tym samym miejscu co dane dostępowe. Kwadrans spędzony na ustaleniu, co się stało, zwykle skraca awarię bardziej niż szybszy monitor.

Błąd 500 i 503 — co mówi monitor

Dwa kody błędów serwera zobaczycie w alertach najczęściej, i znaczą co innego.

500 według specyfikacji HTTP oznacza, że serwer napotkał „an unexpected condition", które uniemożliwiło obsłużenie żądania. Czyli: coś się zepsuło i serwer nie wie co. Przy stronie na WordPressie najczęściej to błąd we wtyczce albo w motywie, często tuż po aktualizacji albo zmianie wersji PHP.

503 oznacza, że serwer jest „currently unable to handle the request due to a temporary overload or scheduled maintenance" — chwilowo przeciążony albo w trakcie planowanych prac. To jest kod, który strona powinna zwracać sama podczas prac serwisowych, najlepiej z nagłówkiem Retry-After, który mówi, kiedy wrócić.

Dla wyszukiwarki różnica jest mniejsza, niż się wydaje. Według Google błędy 5xx — oba te kody i 429 — powodują, że Googlebot chwilowo zwalnia pobieranie strony. Zaindeksowane adresy zostają w indeksie, ale te, które zwracają błąd serwera trwale, są z niego ostatecznie usuwane. Krótka awaria nie zaszkodzi. Strona, która zwraca 500 przez kilka dni, bo nikt nie dostał alertu — zaszkodzi.

Co znaczy każdy z kodów serwera — także 502 i 504, które też zobaczycie w alertach — i kogo przy którym wołać, rozkładamy w osobnym tekście o błędach serwera.

Stąd zasada dla prac planowanych: jeśli strona ma być niedostępna, niech zwraca 503, a nie stronę „w przebudowie" z kodem 200. Ta druga dla Google jest nową treścią pod tym adresem, i to gorszą niż nasz soft 404 z początku tego tekstu: tamten ma przynajmniej znacznik noindex, strona „w przebudowie" zwykle nie ma żadnego.

Awarie z datą w kalendarzu: certyfikat i domena

Większości awarii nie da się przewidzieć. Dwie — da się co do dnia.

Certyfikat. Maksymalna ważność certyfikatów stron skróciła się w marcu 2026 roku do 200 dni i będzie dalej spadać — terminy rozkładamy przy certyfikatach SSL. Przy automatycznym odnawianiu problem zwykle nie istnieje, dopóki automat działa. Kiedy przestanie — bo zmienił się serwer, DNS albo konfiguracja — dowiecie się w dniu, w którym przeglądarki zaczną pokazywać odwiedzającym ostrzeżenie. Monitor daty certyfikatu zamienia to w powiadomienie z tygodniowym wyprzedzeniem.

Domena. Wygasła domena wyłącza naraz stronę i pocztę, a po okresie przywracania może ją zarejestrować ktokolwiek — co opisujemy przy kosztach utrzymania. Najczęstszą przyczyną nie jest brak pieniędzy, tylko przypomnienie wysłane na adres, którego nikt nie czyta. Monitor daty domeny jest drugim przypomnieniem, niezależnym od rejestratora.

Oba sprawdzenia są w większości narzędzi do monitoringu dostępne od ręki, a ustawia się je raz.

Monitoring serwera — co widać tylko od środka

Wszystko, co opisaliśmy do tej pory, sprawdza stronę z zewnątrz, tak jak widzi ją klient. Monitoring serwera patrzy od środka: na zajęte miejsce na dysku, obciążenie procesora, pamięć, błędy zapisywane w dziennikach i zadania uruchamiane cyklicznie. Przy hostingu współdzielonym większość z tego jest poza Waszym zasięgiem i to dostawca odpowiada za to, co się dzieje w środku. Przy własnym serwerze albo serwerze wirtualnym — to Wasza odpowiedzialność albo wykonawcy.

Z punktu widzenia właściciela strony dwie rzeczy są tu ważniejsze od reszty, bo są częstymi przyczynami awarii, które z zewnątrz wyglądają na nagłe:

• Miejsce na dysku. Dziennik, który rośnie bez ograniczeń, albo kopie zapasowe zapisywane na tym samym serwerze potrafią zapełnić dysk w ciągu tygodni. Kiedy miejsca zabraknie, przestaje działać wszystko, co cokolwiek zapisuje — łącznie z formularzami i bazą danych. Alert przy zajętości przekraczającej ustalony próg daje na to tygodnie zamiast minut.
• Zadania, które nie wykonały się po cichu. Kopia zapasowa, która nie powstała, odnowienie certyfikatu, które się nie udało, wysyłka powiadomień, która stanęła. Z zewnątrz strona działa, a problem ujawni się dopiero wtedy, kiedy ta kopia albo ten certyfikat będą potrzebne. Dobre ustawienie polega na tym, żeby alarm podnosił brak sygnału o udanym wykonaniu, a nie tylko błąd.

Jeśli stroną opiekuje się wykonawca, monitoring serwera jest jego narzędziem pracy. Dla Was wystarczy wiedzieć, że istnieje, i raz w miesiącu dostawać z niego jedno zdanie: czy kopie się wykonały i ile zostało miejsca.

Monitoring wydajności to nie Core Web Vitals

Monitor dostępności mierzy też czas odpowiedzi serwera, i warto na niego patrzeć — nagły wzrost bywa pierwszym objawem problemu, zanim strona przestanie odpowiadać. Ale to nie są dane, na które patrzy Google.

Google ocenia szybkość strony na podstawie Core Web Vitals, czyli pomiarów od prawdziwych użytkowników Chrome, zbieranych jako średnia z 28 dni. To ważne dane, ale nie nadają się do alarmowania: zmiana na gorsze pojawi się w nich stopniowo, przez kolejne tygodnie, a nie w godzinę po wdrożeniu, które ją spowodowało. Monitoring wydajności i Core Web Vitals odpowiadają więc na dwa różne pytania — „czy coś właśnie się zepsuło" i „jak strona wypada dla użytkowników w ostatnim miesiącu" — i jedno nie zastąpi drugiego.

Czego w tym tekście świadomie nie ma

• Monitorowania pozycji w Google — to inne narzędzia i inne pytanie; opisujemy je przy pozycjonowaniu strony.
• Analityki ruchu — analityka strony mówi, kto przyszedł, a nie, czy strona działała.
• Dostępności w sensie WCAG — „dostępność strony" to także zgodność ze standardami dla osób z niepełnosprawnościami; to osobny temat.
• Tego, co zrobić po awarii — przywracanie z kopii zapasowej i ustalenia z wykonawcą, kto reaguje i w jakim czasie, czyli obsługa strony.

Najkrótsze podsumowanie: monitor pytający tylko o kod 200 powie Wam, że serwer żyje — nie, że strona działa. Dodajcie sprawdzenie treści, daty certyfikatu i domeny, a przy sklepie — całą ścieżkę zakupu. I zanim wybierzecie narzędzie, zapiszcie, kto dostanie alert o trzeciej w nocy i co może z nim zrobić, bo to ten odcinek, a nie częstotliwość sprawdzania, decyduje o tym, ile trwa awaria.