Monitoring strony i sklepu: co sprawdzać codziennie, co raz w tygodniu i co raz w miesiącu

Monitoring strony internetowej sklepu, co sprawdzać i jak często, to pytanie, które większość właścicieli zadaje dopiero po pierwszej poważnej awarii. Tymczasem każda godzina niedziałającej strony to utracone zamówienia, leady i zaufanie klientów, którzy nie czekają. Ten wpis daje konkretną checklistę z podziałem na częstotliwość i tłumaczy, które alerty ustawisz sam w 15 minut, a które wymagają zewnętrznego narzędzia lub dostawcy.

Dlaczego klient nie powinien być Twoim pierwszym alertem?

Statystyczny właściciel sklepu e-commerce dowiaduje się o awarii po 4 do 8 godzin od jej wystąpienia. Najczęstszym źródłem informacji jest klient, który napisał, że "coś nie działa z zamówieniem". Dla strony B2B z 3 leadami tygodniowo godzina niedostępności może oznaczać utratę jedynego kontaktu z tego dnia.

Trzy scenariusze, które powtarzają się najczęściej:

Sklep e-commerce z obrotem 100 tys. PLN miesięcznie zarabia średnio około 140 PLN na minutę. Awaria trwająca 6 godzin bez alertu to potencjalnie ponad 50 tys. PLN utraconych przychodów, zanim ktokolwiek zareaguje.

Strona B2B z formularzem kontaktowym. Webhook do CRM przestaje działać po aktualizacji wtyczki. Formularze przyjmują zgłoszenia, ale nikt ich nie otrzymuje. Właściciel dowiaduje się po tygodniu, gdy klient dzwoni z pytaniem, dlaczego nikt nie oddzwonił.

Strona wizytówkowa z certyfikatem SSL wygasłym o 3 dni. Przeglądarki blokują wejście, wyświetlając ostrzeżenie "Twoje połączenie nie jest prywatne". Użytkownik wychodzi. Google zaczyna obniżać częstotliwość crawlowania.

Proaktywny monitoring skraca czas wykrycia awarii do 1-3 minut. To różnica między stratą a incydentem.

Co sprawdzać codziennie (lub automatycznie co 1-5 minut)?

Dostępność strony (uptime monitoring)

Narzędzie wysyła żądanie HTTP do Twojej strony co 1-5 minut i sprawdza, czy odpowiada kodem 200. Jeśli dostanie kod 500, 503 lub brak odpowiedzi, wysyła alert na e-mail, SMS lub do Slacka.

Próg alarmowy: każda niedostępność dłuższa niż 5 minut wymaga reakcji.

Narzędzia: UptimeRobot (bezpłatny, sprawdza co 5 minut, wystarczy dla większości stron wizytówkowych), Better Uptime lub Freshping (płatne, sprawdzają co 1 minutę, mają lepsze raporty SLA).

Czy możesz to ustawić sam? Tak. Rejestracja i konfiguracja w UptimeRobot zajmuje 10 minut.

Czas odpowiedzi serwera (TTFB)

TTFB (Time to First Byte) to czas, w jakim serwer zaczyna odsyłać odpowiedź po otrzymaniu żądania. Google zaleca TTFB poniżej 800 ms. Powyżej 1800 ms strona jest klasyfikowana jako wolna i wpływa to bezpośrednio na Core Web Vitals.

UptimeRobot i Better Uptime mierzą TTFB przy każdym sprawdzeniu. Ustaw alert gdy TTFB przekroczy 2000 ms, nagły wzrost to często sygnał przeciążenia serwera lub problemu z bazą danych.

Certyfikat SSL (ważność i poprawność)

Wygaśnięty certyfikat blokuje wejście na stronę dla wszystkich przeglądarek. Większość dostawców certyfikatów odnawia je automatycznie, ale automatyzacja czasem zawodzi.

Ustaw alert na 30 dni przed wygaśnięciem. UptimeRobot monitoruje SSL bezpłatnie. Sprawdź też, czy certyfikat pokrywa subdomenę www i domenę bez www.

Status płatności w sklepie (bramka, webhook)

Bramka płatności może działać technicznie, ale webhook potwierdzający zamówienie może przestać wysyłać dane do sklepu po aktualizacji CMS lub wtyczki. Efekt: zamówienie jest opłacone, ale sklep nie zmienia jego statusu.

Sprawdzaj raz dziennie: czy ostatnie zamówienia zmieniły status po płatności. Jeśli masz testową kartę płatniczą, zrób transakcję testową raz w tygodniu i sprawdź, czy status w sklepie się zmienił.

Co sprawdzać raz w tygodniu?

Logi błędów serwera (404, 500, 503)

Logi serwera pokazują, które adresy URL zwracają błędy i jak często. Masowe błędy 404 mogą oznaczać zepsute linki po migracji lub przebudowie menu. Błędy 500 i 503 wskazują na problemy z aplikacją lub przeciążenie serwera.

Gdzie szukać: panel hostingu (sekcja logi), Google Search Console (raport Indeksowanie, zakładka Strony), wtyczka do WordPress (np. WP Activity Log).

Raz w tygodniu wystarczy przejrzeć raport i sprawdzić, czy pojawiły się nowe błędy 5xx.

Rozmiar bazy danych i wolna przestrzeń dyskowa

Baza danych sklepu WooCommerce rośnie szybko, szczególnie jeśli nie czyścisz tabel sesji, logów i rewizji postów. Pełny dysk = awaria strony bez ostrzeżenia.

Sprawdzaj w panelu hostingu raz w tygodniu: ile miejsca zostało. Ustaw alert, gdy zostaje mniej niż 20% wolnej przestrzeni.

Skuteczność kopii zapasowych

Backup, który istnieje, ale nie da się go przywrócić, nie jest backupem. Raz w tygodniu sprawdź, czy backup faktycznie powstał w zaplanowanym czasie. Raz w miesiącu przywróć go testowo na środowisku stagingowym. Jak skonfigurować backup, żeby faktycznie działał, opisuję szczegółowo w osobnym wpisie na blogu.

Aktualizacje CMS, wtyczek i zależności

Przestarzałe wtyczki to najczęstszy wektor ataku na strony WordPress i WooCommerce. Raz w tygodniu sprawdź panel aktualizacji. Aktualizuj wtyczki pojedynczo, nie wszystkie naraz, żeby łatwiej wychwycić, która powoduje konflikt.

Co sprawdzać raz w miesiącu?

Core Web Vitals (LCP, CLS, INP)

Core Web Vitals to trzy wskaźniki, które Google uwzględnia w rankingach:

• LCP (Largest Contentful Paint): czas ładowania największego elementu widocznego na ekranie. Cel: poniżej 2,5 s.

• CLS (Cumulative Layout Shift): stabilność układu strony podczas ładowania. Cel: poniżej 0,1.

• INP (Interaction to Next Paint): responsywność na kliknięcia i dotknięcia. Cel: poniżej 200 ms.

Gdzie sprawdzać: Google Search Console (raport Core Web Vitals), PageSpeed Insights (dla konkretnego URL).

Indeksacja w Google Search Console

Raz w miesiącu sprawdź raport Indeksowanie w GSC:

• Czy liczba zaindeksowanych stron nie spadła nagle?

• Czy nie pojawiły się strony wykluczone przez robots.txt lub metatag noindex przez pomyłkę?

• Czy nie ma błędów crawlowania na kluczowych podstronach (oferta, sklep, kontakt)?

Nagły spadek liczby zaindeksowanych stron to sygnał wymagający natychmiastowej reakcji.

Bezpieczeństwo: skany malware i zmiany w plikach systemowych

Złośliwy kod najczęściej jest wstrzykiwany w pliki motywu lub wtyczek i przez tygodnie pozostaje niezauważony. Raz w miesiącu uruchom skan malware (Wordfence dla WordPress, Imunify360 po stronie serwera przy dobrym hostingu).

Sprawdź też integralność plików systemowych CMS, czy żaden plik rdzenia nie został zmodyfikowany.

Raport SLA od dostawcy hostingu

Jeśli Twój dostawca deklaruje 99,9% uptime, raz w miesiącu sprawdź, czy rzeczywiście dotrzymuje tej obietnicy. Better Uptime i podobne narzędzia generują raport miesięczny z faktycznym uptime w procentach.

Decyzja o wyborze hostingu wpływa na SLA i dostępność przez lata, dlatego warto weryfikować deklaracje dostawcy twardymi danymi, nie tylko deklaracjami w regulaminie.

Które alerty ustawić samodzielnie, a które wymagają narzędzia lub dostawcy

Dla sklepu e-commerce z codzienną sprzedażą minimum to poziom podstawowy wdrożony samodzielnie i poziom zaawansowany po stronie dostawcy. Samodzielny UptimeRobot informuje po fakcie. Dostawca z proaktywnym monitoringiem i izolacją zasobów NVMe interweniuje zanim klient zauważy problem.

Reaktywny vs. proaktywny monitoring: co to znaczy w praktyce

Reaktywny monitoring to sprawdzanie raz na jakiś czas albo dowiadywanie się o problemie od klienta. Koszt: czas reakcji 4-8 godzin, pełny koszt awarii.

Proaktywny monitoring to system, który sprawdza co minutę i wysyła alert zanim klient zauważy problem. Czas reakcji: 1-8 minut od wystąpienia awarii.

Przykład: sklep z 80 zamówieniami dziennie zarabia średnio jedno zamówienie co 18 minut. Awaria trwająca 2 godziny bez monitoringu to 6-7 utraconych zamówień i klienci, którzy poszli do konkurencji. Z monitoringiem i SLA po stronie dostawcy ta sama awaria trwa 8-15 minut, zanim technik zareaguje. Różnica w przychodach to nie filozofia, to liczba w raporcie miesięcznym.

Checklista: monitoring strony i sklepu

Codziennie (automatycznie, 0 minut Twojego czasu): - Uptime strony co 1-5 minut (UptimeRobot lub Better Uptime) - Alert SSL na 30 dni przed wygaśnięciem - Alert TTFB powyżej 2000 ms - Status ostatnich zamówień (czy płatności zmieniają status)

Raz w tygodniu (ręcznie, 10-15 minut): - Przegląd logów błędów 4xx i 5xx - Wolna przestrzeń dyskowa (alert poniżej 20%) - Czy backup powstał w zaplanowanym czasie - Aktualizacje CMS i wtyczek (po jednej, nie wszystkie naraz)

Raz w miesiącu (ręcznie, 15-20 minut): - Core Web Vitals w Google Search Console - Raport indeksacji w GSC (czy liczba stron nie spadła) - Skan malware i integralność plików - Raport uptime od dostawcy vs. deklarowane SLA

Jeśli wolisz, żeby monitoring był po stronie dostawcy, a nie Twojej, sprawdź szczegóły infrastruktury i utrzymania strony.