Monitoring uptime strony - jak wykryć awarię zanim zrobi to klient

Klient pisze do mnie o 9:00 rano: "Dawid, od kiedy nie działa sklep? Zamówień brak od wczoraj wieczór." Sprawdzam logi - serwer leżał od 21:47. Ponad 11 godzin przestoju, kompletnie niezauważonego. Tamten klient miał szczęście, że akurat nie był w szczycie sezonu.

To był 2018 rok i od tamtej pory pilnuję, żeby żadna ze stron w mojej opiece nie dowiedziała się o awarii od klienta. Monitoring uptime strony to jedna z pierwszych rzeczy, którą ustawiam po każdym wdrożeniu.

Co tak naprawdę robi monitoring uptime

Chodzi o prostą zasadę: zewnętrzny serwer co kilka minut odpytuje Twoją stronę pod adresem HTTPS i sprawdza, czy dostał odpowiedź z kodem 200 (czyli: "wszystko działa"). Jeśli zamiast tego przychodzi błąd 500, timeout albo brak odpowiedzi w ogóle, system natychmiast wysyła alert.

Monitoring uptime strony wykrywa takie sytuacje:

• serwer nie odpowiada (hosting ma awarię, VPS skończył RAM)
• strona zwraca błąd PHP (popsuta aktualizacja wtyczki, konflikt motywu)
• certyfikat SSL wygasł i przeglądarka blokuje dostęp
• strona ładuje się, ale za wolno (timeout powyżej np. 10 sekund)
• domena nie jest już podpięta do serwera (błąd DNS)

Bez takiego narzędzia dowiadujesz się o awarii albo przypadkowo, albo od klienta.

Ile może kosztować brak monitoringu

Liczby są proste do oszacowania. Jeśli sklep generuje 50 000 zł miesięcznie, to dziennie to około 1 666 zł. Godzina to 69 zł. Brzmi skromnie, ale awarie rzadko zdarzają się w niedzielę o 3 w nocy - zdarzają się w piątki po południu, przy wzmożonym ruchu reklamowym, podczas kampanii mailingowych.

Do tego dochodzi coś trudniejszego do policzenia: zaufanie. Klient, który trzy razy z rzędu trafi na niedostępną stronę, po prostu idzie do konkurencji. Bez reklamacji, bez maila, po cichu.

Miałem projekt, gdzie sklep z artykułami dla dzieci padał w każdy piątek wieczór - akurat wtedy, gdy rodzice robili zakupy po pracy. Przyczyną był cron WordPressa zakleszczający bazę danych co tydzień. Monitoring powiadamiał o tym o 18:05, ja naprawiałem do 18:30. Bez alertu trwałoby do poniedziałku rano.

Trzy narzędzia, które faktycznie warto znać

UptimeRobot to najczęściej polecane narzędzie dla małych projektów. W planie darmowym sprawdza do 50 stron co 5 minut i wysyła powiadomienia emailem. Od 2025 roku plan darmowy jest przeznaczony formalnie do użytku niekomercyjnego, więc dla sklepów produkcyjnych warto rozważyć plan Solo ($7/mc), który skraca interwał do 1 minuty i dodaje monitorowanie certyfikatów SSL. Publiczna strona statusu (np. status.twojafirma.pl) jest dostępna już w planie darmowym.

Better Stack (dawniej Better Uptime) to moim zdaniem najlepszy wybór jeśli zależy Ci na reakcji na incydenty, nie tylko alertach. Darmowy tier obejmuje nielimitowane alerty SMS i telefoniczne, wbudowany incident management i eleganckie strony statusu. Płatne plany startują od $24/mc za team. Dla agencji obsługujących kilkanaście klientów to wygodniejsza opcja niż UptimeRobot.

Uptime Kuma to open source do samodzielnego hostowania. Bezpłatny, obsługuje ponad 90 kanałów powiadomień (w tym Telegram, Slack, Discord, email przez SMTP, PagerDuty). Wymaga własnego serwera lub taniego VPS - liczy się tutaj Docker albo Node.js. Polecam klientom technicznych, którzy mają już serwer dedykowany lub VPS i chcą mieć pełną kontrolę bez abonamentów.

Jak ustawić powiadomienia, żeby faktycznie działały

Największym błędem jest konfigurowanie tylko jednego kanału powiadomień. Masz alert wyłącznie na email? Co się stanie, gdy akurat nie sprawdzasz skrzynki przez 4 godziny? Albo gdy alert trafi do spamu?

Minimum, które wdrażam u każdego klienta w opiece technicznej WordPress:

1. Email na adres firmowy - zawsze jako pierwsza linia
2. Drugi kanał: SMS, Telegram lub telefon - coś, co dotrze gdy nie masz otwartej skrzynki
3. Opóźnienie alertu "powrót do normy" - żeby wiedzieć, kiedy awaria minęła bez konieczności logowania się co chwilę

Ważne: w Better Stack i UptimeRobot możesz ustawić, żeby alert nie wychodził po pierwszej nieudanej próbie, lecz dopiero po 2-3 kolejnych. To eliminuje fałszywe alarmy (jednorazowy timeout sieciowy) i nie budzi właściciela o 3 w nocy z powodu sekundowej chwilowej niedostępności.

Co sprawdzić dodatkowo poza HTTP

Monitor HTTP to fundament, ale są jeszcze trzy rodzaje monitorów, które wdrażam przy poważniejszych projektach.

Monitor certyfikatu SSL - certyfikaty Let's Encrypt ważne 90 dni, certyfikaty komercyjne 1-2 lata. Zapomnienie o odnowieniu to najczęstszy powód, dla którego klienci dzwonią z krzykiem "strona pokazuje błąd bezpieczeństwa". Alert 30 dni wcześniej daje czas na reakcję.

Monitor keyword - sprawdza, czy strona nie tylko odpowiada, ale zawiera konkretny tekst. Ustawiam np. sprawdzanie, czy na stronie jest słowo "koszyk" - jeśli nie ma (bo strona zwróciła pustą stronę błędu zamiast sklepu), alert wychodzi mimo kodu 200.

Monitor portu - dla zaawansowanych: sprawdzanie portów 25/587 (poczta), 3306 (MySQL), 6379 (Redis). Przydatne gdy serwer odpowiada przez HTTP, ale aplikacja ma problem z bazą danych w środku.

Reagowanie na alert - co robić w pierwszych 10 minutach

Otrzymałeś alert o awarii. Co dalej?

Pierwsze 2 minuty: sprawdź, czy to Twoja strona, czy problem ogólny. Otwórz stronę w trybie incognito z telefonu (inny adres IP, brak cache). Wejdź na panel hostingowy i sprawdź status serwera. Większość dostawców hostingu ma własną stronę statusu.

Minuty 3-5: jeśli serwer odpowiada, zaloguj się przez SSH lub FTP i sprawdź logi PHP (error_log) oraz logi serwera www. Najczęstsze przyczyny w WordPress to: plugin po aktualizacji rzucający błąd fatal error, wyczerpanie limitu pamięci PHP (zwiększ memory_limit w wp-config.php), zakleszczona baza danych lub atak brute-force blokujący zasoby.

Minuty 5-10: jeśli nie możesz samodzielnie zidentyfikować przyczyny, kontaktuj się z obsługą hostingu - podaj dokładny czas awarii z logów monitora. To przyspiesza diagnostykę po ich stronie.

Do klientów w abonamencie mam też gotową procedurę: automatyczne powiadomienie SMS z linkiem do wewnętrznego statusu, żeby wiedzieli, że sprawa jest pod kontrolą, bez konieczności dzwonienia do mnie.

Monitoring w kontekście opieki technicznej

Jeśli zlecasz komuś opiekę techniczną WordPress, monitoring uptime powinien być wymieniony explicite w umowie - kto monitoruje, z jakim interwałem, na jaki numer alarmowy i jaki jest gwarantowany czas reakcji. To nie jest optional feature - to podstawa.

Sam wdrożyłem monitoring dla kilkudziesięciu projektów przez ostatnie lata. Zestaw, który stosuję najczęściej przy stronach firmowych: Better Stack (darmowy tier, alerty SMS) plus monitor SSL w UptimeRobot jako backup. Dla sklepów WooCommerce dodaję jeszcze monitor keyword na stronie produktu i cron monitor sprawdzający, czy kolejka zamówień w WooCommerce nie zamarła.

Warto sprawdzić też jak wygląda historia uptime obecnego hostingu zanim zdecydujesz się na przedłużenie umowy. Jeśli monitoring pokazuje 98,5% uptime w ciągu roku, to ponad 130 godzin niedostępności - to zły wynik. Dobry hosting dla WordPressa powinien mieć 99,9% lub więcej. Pisałem o tym przy okazji wyboru hostingu dla WordPressa i aktualizacjach wtyczek WordPress bez psucia strony.

Gdzie postawić granicę: free vs. płatny plan

Dla strony wizytówkowej małej firmy plan darmowy UptimeRobot albo Better Stack w zupełności wystarczy. Interwał 5 minut jest akceptowalny, alerty emailowe spełniają swoją rolę.

Płatny plan warto rozważyć gdy:

• prowadzisz sklep internetowy z codziennymi zamówieniami
• masz aktywne kampanie Google Ads lub Meta Ads (płacisz za ruch na niedziałającą stronę)
• obsługujesz klientów B2B z umowami SLA
• strona jest punktem krytycznym dla rezerwacji lub sprzedaży biletów

W tych przypadkach $7-24 miesięcznie za lepszy monitoring to koszt poniżej jednej utraconej sprzedaży. Rachunek jest prosty.