Monitoring WordPress – uptime, wydajność, logi i reagowanie na awarie
Opublikowano: 21 maja 2026 · Autor: Marcin Szewczyk-Wilgan
WordPress nie informuje administratora o tym, że strona przestała działać. Nie wysyła powiadomienia, gdy PHP wyczerpie pamięć, baza danych przestanie odpowiadać albo serwer zwróci błąd 500. Bez zewnętrznego monitoringu możesz dowiedzieć się o awarii dopiero wtedy, gdy zadzwoni klient albo Google zacznie deindeksować stronę. Tymczasem każda minuta niedostępności to utracone zamówienia, spadek zaufania i pogorszenie pozycji w wyszukiwarce. Monitoring to nie luksus zarezerwowany dla dużych serwisów. To podstawowy element utrzymania każdej strony WordPress, która ma znaczenie biznesowe. Ten artykuł opisuje wszystkie warstwy monitoringu, od prostego sprawdzania dostępności po zaawansowaną analizę logów, i wyjaśnia, jak skonfigurować system, który wykryje problem zanim dotknie użytkowników.
Monitoring uptime: czy strona odpowiada?
Monitoring uptime to najprostsza i jednocześnie najważniejsza warstwa. Zewnętrzna usługa regularnie wysyła żądanie HTTP do Twojej strony i sprawdza, czy otrzymuje prawidłową odpowiedź. Jeśli strona nie odpowiada lub zwraca błąd, natychmiast dostajesz powiadomienie. Bez tego działasz w ciemno.
/wp-json/), stronę logowania (/wp-login.php) i w przypadku WooCommerce stronę checkout. Każdy z tych endpointów może zawodzić niezależnie. Strona główna może działać z cache, podczas gdy REST API zwraca błąd 500 z powodu awarii bazy danych.
Synthetic Monitoring vs Real User Monitoring (RUM)
Monitoring uptime odpowiada na pytanie „czy strona działa?". Monitoring wydajności odpowiada na pytanie „jak szybko działa i jakie doświadczenie ma użytkownik?". W 2026 roku wyróżniamy dwa uzupełniające się podejścia: Synthetic Monitoring (testy syntetyczne) i Real User Monitoring (monitoring rzeczywistych użytkowników).
Kontrolowane testy z zewnątrz
Synthetic Monitoring to automatyczne testy wykonywane przez roboty z kontrolowanych lokalizacji, na kontrolowanych urządzeniach i połączeniach. Symulują wizytę na stronie i mierzą TTFB, LCP, INP, CLS i czas pełnego załadowania. Działają 24/7 niezależnie od ruchu na stronie, więc wykrywają problemy nawet w nocy, gdy nikt nie odwiedza witryny. Są powtarzalne, co czyni je idealnymi do porównywania wydajności przed i po zmianach (np. po aktualizacji WordPress).
Dane od prawdziwych użytkowników
Real User Monitoring zbiera metryki wydajnościowe bezpośrednio z przeglądarek odwiedzających. Pokazuje, jak strona działa na prawdziwych urządzeniach (iPhone 12 na 4G vs MacBook Pro na światłowodzie), w prawdziwych lokalizacjach i z prawdziwym cache przeglądarki. RUM ujawnia problemy, których testy syntetyczne nie złapią: wolne ładowanie na konkretnym modelu telefonu, problem z CDN w danym regionie, conflict JavaScript na specyficznej wersji przeglądarki. Dane RUM zasilają Core Web Vitals w Google Search Console.
Podejście kombinowane
Synthetic Monitoring jest baseline'em, który powinien działać na każdej stronie. Wykrywa awarie, regresje wydajnościowe i problemy z dostępnością niezależnie od ruchu. RUM jest wartościowy na stronach z wystarczającym ruchem (powyżej kilku tysięcy odsłon miesięcznie), gdzie daje statystycznie istotne dane o doświadczeniu użytkowników. Najskuteczniejsza strategia łączy oba: syntetyczne testy jako ciągły benchmark, RUM jako okno na rzeczywiste doświadczenie.
Jak często sprawdzać
Sklepy WooCommerce i strony z transakcjami online: uptime co 30 sekund, syntetyczny test wydajności co 5 minut. Strony firmowe i blogi: uptime co 1 do 3 minut, syntetyczny test co 15 do 30 minut. Krytyczne endpointy (checkout, API płatności, webhook) zasługują na agresywniejszy interwał niż strony informacyjne. Wyższy interwał = szybsze wykrycie, ale też wyższy koszt usługi monitorującej.
WordPress Site Health: wbudowana diagnostyka
WordPress od wersji 5.1 oferuje narzędzie Site Health dostępne w panelu pod Narzędzia → Kondycja witryny. To nie jest monitoring ciągły, lecz diagnostyka na żądanie, która sprawdza konfigurację i identyfikuje potencjalne problemy. Jest często pomijana przez administratorów, a daje wiele cennych informacji.
Analiza logów serwera
Logi to pamięć serwera. Każde żądanie, każdy błąd, każda wolna transakcja zostawia ślad w logach. Większość administratorów WordPress zagląda do logów dopiero po awarii, ale regularna analiza pozwala wykryć narastające problemy zanim przerodzą się w widoczne dla użytkowników przestoje.
Błędy krytyczne i ostrzeżenia
Log błędów PHP (konfigurowany w php.ini parametrem error_log) rejestruje fatal errors, warnings, notices i deprecation notices. Fatal error PHP natychmiast kończy działanie skryptu i generuje biały ekran lub błąd 500. Włącz WP_DEBUG_LOG w wp-config.php, żeby WordPress zapisywał błędy do pliku wp-content/debug.log. Na produkcji ustaw WP_DEBUG na false, ale WP_DEBUG_LOG na true, żeby logować błędy bez wyświetlania ich użytkownikom.
Wzorce ruchu i kody odpowiedzi
Log dostępu Nginx lub Apache rejestruje każde żądanie HTTP z kodem odpowiedzi, rozmiarem, czasem obsługi i adresem IP. Rosnąca liczba odpowiedzi 404 może oznaczać uszkodzone linki lub skanowanie struktury strony. Seria odpowiedzi 500 to sygnał awarii PHP lub bazy danych. Nagły wzrost żądań do /wp-login.php oznacza atak brute force. Analiza logów dostępu to fundament proaktywnego utrzymania.
Wolne zapytania do bazy danych
MySQL slow query log rejestruje zapytania przekraczające ustalony próg czasu (rekomendujemy 1 sekundę na start). Jeden wolny zapytanie powtarzane przy każdym załadowaniu strony potrafi spowolnić cały serwis. Analiza slow query log wskazuje dokładnie, które zapytania wymagają optymalizacji bazy danych: brakujące indeksy, zapytania bez LIMIT, pełne skany tabel wp_postmeta i wp_options.
Od ręcznej analizy do automatycznych alertów
Ręczne przeglądanie logów jest wartościowe, ale nie skaluje się. Na serwerach Linux narzędzia takie jak Logwatch, GoAccess i Logrotate automatyzują analizę i rotację logów. Fail2Ban reaguje na wzorce ataków w logach. Bardziej zaawansowane rozwiązania (Grafana Loki, ELK Stack) agregują logi z wielu źródeł, umożliwiają przeszukiwanie i tworzenie alertów na podstawie reguł. Dla stron w ramach opieki WordPress konfigurujemy automatyczną analizę logów jako element standardowy.
Konfiguracja alertów i eskalacja
Monitoring bez alertów to monitoring, którego nikt nie czyta. Prawidłowo skonfigurowane alerty informują właściwą osobę we właściwym momencie, bez zalewania szumem, który prowadzi do ignorowania powiadomień.
Procedura reagowania na awarię
Gdy monitoring wykryje awarię, liczy się czas i metodyczność. Poniższa procedura pozwala szybko zidentyfikować i naprawić problem, minimalizując czas niedostępności strony.
curl -I https://twoja-strona.pl z serwera. Wyklucz fałszywy alarm. Jeśli strona działa z Twojej lokalizacji, problem może dotyczyć konkretnego regionu, CDN lub DNS.
systemctl status nginx php-fpm mysql), log błędów PHP (ostatnie wpisy), logi serwera WWW (kody odpowiedzi), zajętość dysku (df -h), zużycie pamięci RAM (free -m) i obciążenie CPU (top). Najczęstsze przyczyny awarii WordPress: wyczerpanie pamięci PHP (memory_limit), pełny dysk (brak miejsca na sesje i cache), awaria MySQL, błąd po aktualizacji wtyczki lub motywu, limit zasobów na hostingu współdzielonym.
Podsumowanie
Monitoring WordPress to wielowarstwowy system, który zaczyna się od prostego sprawdzania dostępności, a kończy na zaawansowanej analizie logów i automatycznych alertach. Minimum dla każdej strony o znaczeniu biznesowym to monitoring uptime z alertem e-mail i SMS, monitoring certyfikatu SSL i regularny przegląd logów błędów PHP. Dla stron z większym ruchem i wymaganiami: Synthetic Monitoring wydajności, RUM zasilający dane Core Web Vitals, analiza slow query log i automatyzacja alertów z eskalacją. Kluczowe jest to, by monitoring działał zanim pojawi się pierwszy problem, bo jego wartość polega na tym, że dowiadujesz się o awarii przed swoimi użytkownikami i klientami.
W WebOptimo monitoring uptime, analiza logów i reagowanie na awarie są częścią każdego planu opieki WordPress. Monitorujemy dostępność co 60 sekund, analizujemy logi, konfigurujemy alerty i reagujemy na incydenty. Jeśli Twoja strona nie ma monitoringu, skontaktuj się z nami zanim będzie za późno.
Najczęstsze pytania o monitoring WordPress
Monitoring uptime to automatyczne sprawdzanie, czy strona jest dostępna i odpowiada prawidłowo. Zewnętrzna usługa sprawdza stronę co 30 do 60 sekund i powiadamia Cię o awarii. Bez monitoringu możesz nie wiedzieć o przestoju przez godziny, bo WordPress nie informuje administratora o niedostępności.
Synthetic Monitoring to automatyczne testy z kontrolowanych lokalizacji, działające 24/7 niezależnie od ruchu. Real User Monitoring (RUM) zbiera dane od prawdziwych użytkowników z ich urządzeń i przeglądarek. Synthetic wykrywa awarie i regresje, RUM pokazuje rzeczywiste doświadczenie. Najlepsza strategia łączy oba podejścia.
WordPress oferuje Site Health (Narzędzia → Kondycja witryny) od wersji 5.1, który sprawdza konfigurację PHP, bazy danych, HTTPS, REST API i aktualizacji. To narzędzie diagnostyczne, nie ciągły monitoring. Nie wysyła alertów o niedostępności. Do ciągłego monitoringu potrzebna jest zewnętrzna usługa.
Sklepy WooCommerce: co 30 do 60 sekund. Strony firmowe i blogi: co 1 do 5 minut. Krytyczne endpointy (checkout, API płatności): co 30 sekund. Monitoring powinien działać z co najmniej dwóch lokalizacji, żeby uniknąć fałszywych alarmów.
Cztery kluczowe logi: error log PHP (błędy krytyczne), access log serwera WWW (kody odpowiedzi, wzorce ruchu), slow query log MySQL (wolne zapytania) i log systemowy (próby logowania SSH, awarie usług). Regularna analiza pozwala wykryć problemy, zanim staną się widoczne.
Potwierdź awarię z innej lokalizacji. Sprawdź status usług serwera, logi błędów PHP, logi serwera WWW, zajętość dysku i zużycie pamięci. Napraw przyczynę, zweryfikuj działanie strony i przeprowadź analizę post-mortem, żeby zapobiec powtórzeniu.
