Monitoring strony 24/7 – co naprawdę powinien sprawdzać?

Właściciel firmy najczęściej dowiaduje się o awarii strony w jeden z dwóch sposobów.

Pierwszy: klient dzwoni i mówi, że witryna nie działa.

Drugi: firma zauważa, że od kilku dni nie pojawiło się żadne zapytanie z formularza.

Obie sytuacje oznaczają, że problem trwał już wcześniej, ale nikt go nie wykrył.

Monitoring strony internetowej powinien skrócić czas pomiędzy wystąpieniem awarii a rozpoczęciem reakcji. Nie powinien jednak ograniczać się do prostego sprawdzania, czy strona główna zwraca kod odpowiedzi 200.

Strona może się otwierać, a jednocześnie:

• formularz może nie wysyłać wiadomości,
• sklep może nie zapisywać zamówień,
• płatności mogą nie działać,
• system rezerwacji może nie pobierać dostępności,
• certyfikat SSL może niedługo wygasnąć,
• baza danych może odpowiadać coraz wolniej,
• backup może nie wykonywać się od kilku dni,
• aplikacja może regularnie restartować się z powodu braku pamięci.

Z punktu widzenia podstawowego monitoringu strona nadal „działa”.

Z punktu widzenia firmy może już tracić klientów i pieniądze.

Czym jest monitoring strony internetowej?

Monitoring strony to regularne, automatyczne sprawdzanie jej dostępności, wydajności i najważniejszych funkcji.

System wykonuje testy w określonych odstępach czasu i zapisuje wyniki. Jeżeli wykryje problem, wysyła alert do osoby odpowiedzialnej.

Najprostszy monitoring może sprawdzać:

• czy domena odpowiada,
• jaki kod HTTP zwraca strona,
• ile trwa odpowiedź serwera.

Bardziej rozbudowany system może dodatkowo kontrolować:

• certyfikat SSL,
• konkretne podstrony,
• formularze,
• API,
• bazę danych,
• procesy aplikacji,
• zasoby serwera,
• zadania automatyczne,
• wykonywanie backupów,
• działanie sklepu lub rezerwacji.

Monitoring nie jest jednym narzędziem ani pojedynczym testem.

Powinien być dopasowany do tego, jak strona rzeczywiście wspiera biznes.

Dlaczego samo sprawdzanie strony głównej nie wystarczy?

Strona główna może być zapisana w pamięci podręcznej i wyświetlać się prawidłowo nawet wtedy, gdy inne elementy serwisu już nie działają.

Możliwa jest sytuacja, w której:

• strona główna działa,
• panel administratora zwraca błąd,
• formularz nie zapisuje danych,
• koszyk nie przechodzi do płatności,
• API nie odpowiada,
• nowe wpisy nie są publikowane,
• system nie wysyła wiadomości.

Prosty test dostępności może uznać taki serwis za całkowicie sprawny.

Dlatego monitoring należy podzielić na kilka poziomów:

1. dostępność domeny,
2. odpowiedź serwera,
3. działanie aplikacji,
4. działanie kluczowych funkcji,
5. stan infrastruktury,
6. skuteczność kopii bezpieczeństwa.

Dopiero połączenie tych elementów daje rzeczywisty obraz działania strony.

Monitoring dostępności strony

Podstawowym zadaniem jest sprawdzenie, czy użytkownik może otworzyć witrynę.

System powinien kontrolować:

• czy domena odpowiada,
• czy serwer nie zwraca błędu,
• czy połączenie nie trwa zbyt długo,
• czy działa prawidłowy adres HTTPS,
• czy przekierowania prowadzą do właściwej wersji strony.

Najczęściej oczekiwanym kodem odpowiedzi jest 200.

Monitoring powinien jednak rozpoznawać także inne sytuacje:

• 301 lub 302 – przekierowanie,
• 403 – brak dostępu,
• 404 – brak strony,
• 500 – wewnętrzny błąd serwera,
• 502 – brak prawidłowej odpowiedzi aplikacji,
• 503 – chwilowa niedostępność usługi,
• 504 – przekroczony czas odpowiedzi.

Problemy z kodami 500 i 502 opisaliśmy dokładniej w poradniku [błąd 500 lub 502 na stronie – co oznacza i jak go naprawić](/blog/blad-500-lub-502-na-stronie-co-oznacza-i-jak-naprawic).

Alert powinien zawierać przynajmniej:

• adres strony,
• wykryty kod błędu,
• godzinę wystąpienia,
• czas odpowiedzi,
• informację, czy problem został potwierdzony kolejnym testem.

Jak często sprawdzać dostępność?

Częstotliwość zależy od znaczenia strony.

Prosta witryna informacyjna może być kontrolowana co kilka minut.

Sklep, system rezerwacji albo aplikacja biznesowa mogą wymagać znacznie częstszego sprawdzania.

Im dłuższy odstęp między testami, tym później zostanie wykryta awaria.

Jeżeli monitoring uruchamia test raz na godzinę, strona może nie działać przez niemal 60 minut, zanim ktokolwiek otrzyma alert.

Dla stron generujących sprzedaż rozsądne są krótkie odstępy oraz potwierdzanie błędu z więcej niż jednej lokalizacji.

To ogranicza zarówno czas wykrycia, jak i liczbę fałszywych alarmów.

Monitoring czasu odpowiedzi

Strona nie musi być całkowicie niedostępna, aby powodować straty.

Może działać, ale odpowiadać coraz wolniej.

Monitoring czasu odpowiedzi pozwala zauważyć stopniowe pogarszanie wydajności.

Warto obserwować:

• czas połączenia,
• czas odpowiedzi serwera,
• czas pobierania strony,
• zmiany względem wcześniejszych wyników,
• różnice pomiędzy lokalizacjami.

Nagły wzrost czasu odpowiedzi może wskazywać na:

• przeciążenie,
• problem z bazą,
• ciężkie zapytanie,
• awarię zewnętrznej usługi,
• brak zasobów,
• nieudaną aktualizację,
• rosnącą liczbę procesów.

Wydajność trzeba analizować jako trend, a nie tylko pojedynczy pomiar.

Jeżeli strona przez kilka tygodni stopniowo zwalnia, jest to sygnał ostrzegawczy, nawet jeżeli nadal zwraca kod 200.

Monitoring certyfikatu SSL

Wygasły certyfikat SSL może spowodować wyświetlenie ostrzeżenia o niebezpiecznym połączeniu.

Dla klienta wygląda to jak poważny problem bezpieczeństwa.

Większość bezpłatnych certyfikatów może odnawiać się automatycznie, ale proces może zawieść z powodu:

• błędnego DNS,
• zmiany konfiguracji,
• problemu z przekierowaniem,
• braku dostępu do domeny,
• błędu serwera,
• nieprawidłowego zadania automatycznego.

Monitoring powinien kontrolować:

• termin ważności certyfikatu,
• zgodność certyfikatu z domeną,
• poprawność łańcucha certyfikacji,
• działanie HTTPS,
• liczbę dni do wygaśnięcia.

Alert powinien pojawić się odpowiednio wcześniej, a nie dopiero w dniu utraty ważności.

Monitoring domeny i DNS

Nawet sprawny serwer nie pomoże, jeżeli domena nie prowadzi do właściwego adresu.

Warto kontrolować:

• rekord A,
• rekord AAAA, jeżeli jest używany,
• rekordy CNAME,
• serwery nazw,
• datę odnowienia domeny,
• zmiany w strefie DNS.

Nieautoryzowana albo przypadkowa zmiana DNS może skierować stronę na niewłaściwy serwer.

Problem może pojawić się także po migracji.

Dlatego po [przeniesieniu strony na inny hosting](/blog/jak-przeniesc-strone-na-inny-hosting-bez-przestoju) monitoring powinien potwierdzić, że ruch trafia już do nowego środowiska i wszystkie kluczowe rekordy działają prawidłowo.

Monitoring formularza kontaktowego

Formularz może wyświetlać komunikat „wiadomość została wysłana”, mimo że firma nigdy jej nie otrzyma.

Powodem może być:

• błąd SMTP,
• problem z autoryzacją,
• odrzucenie wiadomości,
• przepełniona skrzynka,
• nieprawidłowy adres odbiorcy,
• blokada antyspamowa,
• błąd wtyczki,
• niedziałający webhook.

Monitoring formularza powinien sprawdzać cały proces:

1. otwarcie podstrony,
2. wypełnienie pól testowych,
3. wysłanie formularza,
4. potwierdzenie poprawnej odpowiedzi,
5. zapis zgłoszenia,
6. opcjonalnie dostarczenie wiadomości.

Nie zawsze trzeba wykonywać taki test co minutę.

Warto jednak regularnie potwierdzać, że formularz rzeczywiście przyjmuje dane.

Jeżeli formularz jest głównym źródłem zapytań, jego monitoring może być ważniejszy niż sprawdzanie samej strony głównej.

Monitoring sklepu internetowego

Sklep może wyglądać poprawnie, ale proces zakupowy może być uszkodzony.

Monitoring WooCommerce lub innej platformy powinien uwzględniać najważniejszą ścieżkę klienta:

• otwarcie produktu,
• dodanie do koszyka,
• wyświetlenie koszyka,
• przejście do zamówienia,
• wybór dostawy,
• dostępność płatności,
• zapis testowego zamówienia.

Nie każdy test powinien wykonywać prawdziwą płatność.

Można jednak sprawdzać:

• odpowiedzi poszczególnych etapów,
• dostępność endpointów,
• działanie koszyka,
• błędy JavaScript,
• poprawność integracji.

Dodatkowo warto monitorować:

• liczbę błędów płatności,
• kolejkę wiadomości e-mail,
• zadania WooCommerce,
• status integracji magazynowych,
• czas odpowiedzi checkoutu.

W artykule [hosting WooCommerce – na czym nie warto oszczędzać](/blog/hosting-woocommerce-na-czym-nie-warto-oszczedzac) opisaliśmy, dlaczego monitoring sklepu powinien wykraczać poza zwykły test dostępności.

Monitoring systemu rezerwacji

System rezerwacyjny może działać częściowo.

Użytkownik widzi stronę, ale:

• kalendarz nie pobiera dostępności,
• cena jest błędnie obliczana,
• rezerwacja nie zapisuje się,
• potwierdzenie nie jest wysyłane,
• płatność nie zmienia statusu,
• synchronizacja z zewnętrznym kanałem nie działa.

Monitoring powinien kontrolować nie tylko stronę publiczną, ale również:

• API dostępności,
• proces zapisu rezerwacji,
• harmonogram synchronizacji,
• kolejki zadań,
• wiadomości potwierdzające,
• połączenie z systemami płatności,
• błędy integracji.

W projektach rezerwacyjnych szczególnie ważne jest sprawdzanie, czy procesy automatyczne wykonują się zgodnie z harmonogramem.

Monitoring API

Aplikacja internetowa może posiadać działający frontend i niedziałający backend.

Użytkownik otwiera stronę, ale nie może:

• zalogować się,
• pobrać danych,
• zapisać formularza,
• utworzyć konta,
• wykonać rezerwacji,
• wyświetlić panelu.

Monitoring API powinien sprawdzać:

• endpoint zdrowia aplikacji,
• czas odpowiedzi,
• kod odpowiedzi,
• strukturę danych,
• dostępność bazy,
• wymagane usługi.

Prosty endpoint `health` może potwierdzać, że proces aplikacji działa.

Bardziej zaawansowany test powinien również sprawdzić, czy aplikacja posiada dostęp do:

• bazy danych,
• Redis,
• kolejki,
• magazynu plików,
• kluczowych usług zewnętrznych.

Sam fakt, że proces Node.js jest uruchomiony, nie oznacza jeszcze, że system może prawidłowo obsłużyć klienta.

Monitoring procesów aplikacji

W aplikacjach Node.js, Next.js, NestJS lub innych systemach trzeba kontrolować procesy działające w tle.

Monitoring może sprawdzać:

• czy proces jest aktywny,
• liczbę restartów,
• wykorzystanie pamięci,
• wykorzystanie procesora,
• czas działania,
• błędy aplikacji,
• nieoczekiwane zakończenia.

Regularne restarty mogą być sygnałem:

• wycieku pamięci,
• przeciążenia,
• nieobsłużonego błędu,
• błędnej konfiguracji,
• problemu z bazą.

Aplikacja może automatycznie wracać do działania po restarcie, dzięki czemu podstawowy monitoring dostępności nie zauważy pełnej skali problemu.

Historia restartów pokazuje jednak, że środowisko jest niestabilne.

Monitoring serwera

Monitoring strony i monitoring serwera to dwa różne poziomy kontroli.

Serwer może działać, ale aplikacja może być niedostępna.

Możliwa jest również odwrotna sytuacja: strona odpowiada, ale infrastruktura zbliża się do krytycznego limitu.

Na serwerze warto kontrolować:

• użycie procesora,
• pamięć RAM,
• swap,
• miejsce na dysku,
• operacje dyskowe,
• obciążenie systemu,
• ruch sieciowy,
• liczbę procesów,
• działanie kluczowych usług.

Alert powinien pojawić się przed całkowitym wykorzystaniem zasobów.

Przykładowo dysk zapełniony w 100% może doprowadzić do:

• zatrzymania bazy,
• braku możliwości zapisu logów,
• błędów sesji,
• nieudanych backupów,
• awarii aplikacji.

Wczesny alert daje czas na reakcję przed niedostępnością strony.

Monitoring bazy danych

Baza może być dostępna, ale działać coraz wolniej.

Warto kontrolować:

• działanie usługi,
• czas połączenia,
• liczbę połączeń,
• wykorzystanie pamięci,
• wielkość bazy,
• wolne zapytania,
• błędy,
• replikację, jeżeli jest używana.

Problem z bazą często objawia się jako:

• wolne ładowanie podstron,
• błędy 500,
• timeouty,
• zawieszanie panelu,
• niedziałający zapis danych.

W przypadku sklepu, systemu rezerwacji lub aplikacji baza jest jednym z najważniejszych elementów infrastruktury.

Jej monitoring powinien być traktowany równie poważnie jak dostępność strony publicznej.

Monitoring kopii zapasowych

Informacja, że backup jest skonfigurowany, nie oznacza, że nadal się wykonuje.

Proces może przestać działać z powodu:

• braku miejsca,
• zmiany hasła,
• problemu z serwerem zewnętrznym,
• błędnej konfiguracji,
• przekroczonego czasu,
• uszkodzenia bazy.

Monitoring kopii powinien sprawdzać:

• datę ostatniego poprawnego backupu,
• rozmiar kopii,
• czas wykonania,
• status procesu,
• miejsce przechowywania,
• ewentualne błędy.

Alert powinien zostać wysłany, gdy:

• kopia się nie wykona,
• backup jest podejrzanie mały,
• ostatnia poprawna kopia jest zbyt stara,
• kończy się miejsce na dane.

Więcej o prawidłowej strategii backupu opisaliśmy w artykule [kopie zapasowe strony – jak często je wykonywać i gdzie przechowywać](/blog/kopie-zapasowe-strony-jak-czesto-i-gdzie-przechowywac).

Monitoring zadań cron

Zadania cron wykonują procesy automatyczne o określonych porach.

Mogą odpowiadać za:

• wysyłanie wiadomości,
• synchronizację danych,
• generowanie raportów,
• import produktów,
• aktualizację cen,
• backup,
• publikację treści,
• usuwanie danych tymczasowych.

Zadanie może przestać działać bez widocznego błędu na stronie.

Monitoring powinien potwierdzać, że proces:

• uruchomił się,
• zakończył prawidłowo,
• wykonał się w oczekiwanym czasie,
• nie wygenerował błędu.

Ważne zadania mogą wysyłać tzw. sygnał powodzenia do systemu monitorującego.

Brak sygnału w określonym czasie oznacza, że proces prawdopodobnie nie został wykonany.

Monitoring poczty transakcyjnej

Strona może generować wiadomości, ale nie oznacza to, że odbiorcy je otrzymują.

Warto kontrolować:

• błędy SMTP,
• liczbę odrzuconych wiadomości,
• kolejkę wysyłki,
• reputację domeny,
• działanie rekordów SPF, DKIM i DMARC,
• opóźnienia w dostarczaniu.

W sklepie lub systemie rezerwacji wiadomości mogą zawierać:

• potwierdzenia,
• dane płatności,
• zmianę statusu,
• reset hasła,
• informacje dla administratora.

Brak tych wiadomości może prowadzić do chaosu w obsłudze klientów, nawet jeżeli strona technicznie działa.

Monitoring bezpieczeństwa

Monitoring bezpieczeństwa nie zastępuje zabezpieczeń, ale pomaga szybciej wykryć podejrzane zdarzenia.

Może obejmować:

• próby logowania,
• zmiany plików,
• nietypowy ruch,
• nieautoryzowane konta administratorów,
• zmiany konfiguracji,
• wykrycie złośliwych plików,
• duży wzrost liczby żądań,
• ataki typu brute force.

Nie każdy wzrost ruchu oznacza atak.

System powinien pomagać odróżnić:

• prawdziwych użytkowników,
• roboty,
• skanery,
• próby nadużycia,
• nietypowe zachowanie.

Najważniejsze alerty powinny trafiać do osoby, która może szybko sprawdzić sytuację.

Monitoring zmian treści

W niektórych projektach warto sprawdzać, czy kluczowa treść strony nie została zmieniona.

Może to dotyczyć:

• numeru konta,
• danych kontaktowych,
• strony logowania,
• komunikatów sprzedażowych,
• cennika,
• fragmentów kodu.

Nieautoryzowana zmiana może być skutkiem:

• włamania,
• błędu edytora,
• wadliwego wdrożenia,
• infekcji.

Monitoring może porównywać wybrane elementy strony i wysyłać alert, gdy treść różni się od oczekiwanej.

Monitoring widoczności w Google

Monitoring techniczny strony nie jest tym samym co monitoring SEO.

Warto jednak obserwować:

• błędy indeksowania,
• niedostępne strony,
• problemy z sitemapą,
• ręczne działania,
• stan najważniejszych adresów,
• nagłe spadki kliknięć i wyświetleń.

Awaria techniczna może przełożyć się na problemy z widocznością, jeżeli trwa długo lub regularnie się powtarza.

Po większej awarii lub migracji warto sprawdzić najważniejsze adresy w Google Search Console.

Monitoring SEO nie zastępuje kontroli serwera, ale pomaga zauważyć skutki problemów technicznych.

Skąd powinien być wykonywany monitoring?

Jeżeli test jest wykonywany wyłącznie z tego samego serwera, może nie wykryć problemu z dostępnością zewnętrzną.

Najlepiej sprawdzać stronę z niezależnego środowiska.

Dla ważniejszych projektów warto wykorzystywać kilka lokalizacji.

Pozwala to odróżnić:

• globalną awarię,
• problem konkretnego operatora,
• błąd regionalny,
• chwilową utratę połączenia.

Jeżeli błąd potwierdzą dwa niezależne punkty monitorujące, prawdopodobieństwo fałszywego alarmu jest znacznie mniejsze.

Jak powinny działać alerty?

Alert ma być użyteczny, a nie tylko głośny.

Powinien zawierać:

• nazwę usługi,
• adres,
• rodzaj problemu,
• godzinę wystąpienia,
• ostatni poprawny wynik,
• aktualny kod lub parametr,
• poziom ważności.

Alerty można podzielić na:

• informacyjne,
• ostrzegawcze,
• krytyczne.

Nie każdy wzrost obciążenia wymaga natychmiastowej pobudki administratora.

Brak działania sklepu, bazy lub API wymaga jednak znacznie szybszej reakcji niż pojedynczy wolniejszy pomiar.

Dobry system ogranicza tzw. zmęczenie alertami.

Jeżeli każda drobna zmiana wysyła alarm, zespół zaczyna ignorować także ważne komunikaty.

Monitoring a reakcja na awarię

Monitoring nie rozwiązuje problemu sam w sobie.

Może wysłać alert, ale nadal potrzebna jest osoba, która:

• sprawdzi zgłoszenie,
• potwierdzi awarię,
• przeanalizuje logi,
• wykona bezpieczne działania,
• przywróci usługę,
• sprawdzi działanie strony.

Dlatego sama informacja „monitoring 24/7” w ofercie nie wystarcza.

Trzeba zapytać:

• kto otrzymuje alert,
• w jakich godzinach jest analizowany,
• jaki jest zakres reakcji,
• czy naprawa jest w cenie,
• co dzieje się poza godzinami pracy,
• czy istnieje procedura awaryjna.

Monitoring bez procesu reakcji jest jedynie systemem powiadomień.

Czas wykrycia i czas przywrócenia

W utrzymaniu stron warto rozróżnić dwa czasy.

**Czas wykrycia** określa, jak szybko system zauważy problem.

**Czas przywrócenia** określa, jak szybko strona wróci do działania.

Monitoring może wykryć awarię w ciągu minuty, ale naprawa może potrwać dłużej, jeżeli:

• nie ma aktualnej kopii,
• brakuje dostępu,
• nie istnieje procedura,
• problem jest złożony,
• serwer trzeba odbudować.

Dlatego monitoring powinien działać razem z:

• backupami,
• dokumentacją,
• dostępami,
• procedurą awaryjną,
• opieką techniczną.

Koszty takiego utrzymania opisaliśmy szerzej w artykule [ile kosztuje utrzymanie strony internetowej miesięcznie](/blog/ile-kosztuje-utrzymanie-strony-internetowej-miesiecznie).

Monitoring hostingu współdzielonego

Na hostingu współdzielonym klient zwykle nie ma dostępu do pełnych parametrów serwera.

Może jednak monitorować:

• dostępność strony,
• czas odpowiedzi,
• SSL,
• formularze,
• kluczowe podstrony,
• pocztę,
• API, jeżeli jest dostępne.

Warto również obserwować limity udostępnione w panelu:

• procesor,
• pamięć,
• liczbę procesów,
• wykorzystanie dysku.

Regularne przekraczanie limitów może oznaczać, że strona wymaga optymalizacji albo zmiany środowiska.

Różnice pomiędzy hostingiem współdzielonym a własnym serwerem opisaliśmy w artykule [VPS czy hosting współdzielony – co wybrać dla firmy](/blog/vps-czy-hosting-wspoldzielony-co-wybrac-dla-firmy).

Monitoring VPS

VPS daje znacznie większe możliwości, ale wymaga bardziej rozbudowanego nadzoru.

Oprócz strony trzeba kontrolować:

• system operacyjny,
• procesy,
• pamięć,
• dysk,
• bazę,
• serwer WWW,
• certyfikaty,
• zadania automatyczne,
• backupy,
• logi bezpieczeństwa.

Własny serwer bez monitoringu może działać z problemem przez wiele dni, dopóki nie dojdzie do całkowitej awarii.

Na VPS szczególnie ważne są alerty dotyczące:

• kończącego się miejsca,
• braku pamięci,
• zatrzymania procesu,
• niedziałającej bazy,
• błędu backupu,
• nietypowego ruchu,
• problemów z certyfikatem.

Czy monitoring może zapobiec awarii?

Nie każdej.

Może jednak pomóc wykryć sygnały ostrzegawcze przed całkowitym zatrzymaniem strony.

Przykłady:

• dysk stopniowo się zapełnia,
• zużycie pamięci rośnie,
• czas odpowiedzi się pogarsza,
• proces coraz częściej się restartuje,
• backup regularnie kończy się błędem,
• certyfikat niedługo wygaśnie.

Bez monitoringu problemy zostaną zauważone dopiero po awarii.

Z monitoringiem można zareagować wcześniej i zaplanować działania bez presji.

Jak dobrać monitoring do rodzaju strony?

Prosta strona firmowa

Powinna mieć przynajmniej:

• monitoring dostępności,
• kontrolę SSL,
• test formularza,
• kontrolę backupu.

WordPress

Dodatkowo warto kontrolować:

• błędy PHP,
• aktualizacje,
• dostępność panelu,
• zmiany plików,
• miejsce na dysku.

Sklep WooCommerce

Monitoring powinien obejmować:

• stronę produktu,
• koszyk,
• checkout,
• zadania WooCommerce,
• pocztę transakcyjną,
• płatności,
• bazę danych.

Aplikacja internetowa

Warto sprawdzać:

• frontend,
• API,
• bazę,
• Redis,
• kolejki,
• procesy,
• zadania cron,
• zasoby serwera.

System rezerwacji

Kluczowe są:

• dostępność kalendarza,
• zapis rezerwacji,
• płatności,
• synchronizacje,
• wysyłka potwierdzeń,
• aktualność danych.

Najczęstsze błędy w konfiguracji monitoringu

Sprawdzanie tylko strony głównej

Nie wykrywa problemów formularza, sklepu ani API.

Zbyt rzadkie testy

Awaria może trwać długo przed wysłaniem pierwszego alertu.

Brak potwierdzenia błędu

Pojedynczy problem z siecią może wygenerować fałszywy alarm.

Brak monitoringu backupów

Firma zakłada, że kopie się wykonują, chociaż proces od dawna nie działa.

Alerty bez osoby odpowiedzialnej

Powiadomienia trafiają do skrzynki, której nikt regularnie nie sprawdza.

Brak procedury reakcji

Zespół wie, że wystąpiła awaria, ale nie wie, od czego rozpocząć diagnozę.

Zbyt wiele alertów

Nadmiar komunikatów powoduje ignorowanie także tych krytycznych.

Monitoring strony z HeatLogic

W HeatLogic monitoring dopasowujemy do roli strony w firmie.

Inaczej kontrolujemy prostą wizytówkę, inaczej sklep, system rezerwacji lub aplikację SaaS.

Zakres może obejmować:

• dostępność strony,
• czas odpowiedzi,
• kody HTTP,
• certyfikat SSL,
• formularze,
• API,
• procesy aplikacji,
• bazę danych,
• zasoby VPS,
• zadania automatyczne,
• backupy,
• alerty techniczne.

Monitoring łączymy z [hostingiem i opieką techniczną HeatLogic](/hosting-i-opieka).

Dzięki temu alert nie trafia wyłącznie do systemu, ale może rozpocząć realną diagnozę problemu.

Nie chodzi o obietnicę, że żadna awaria nigdy się nie wydarzy.

Chodzi o to, aby problem został szybko wykryty, właściwie oceniony i możliwie sprawnie usunięty.

Lista kontrolna monitoringu strony

Sprawdź, czy monitoring obejmuje:

1. Dostępność strony głównej.
2. Najważniejsze podstrony.
3. Kody odpowiedzi HTTP.
4. Czas odpowiedzi.
5. Certyfikat SSL.
6. Termin ważności domeny.
7. DNS.
8. Formularz kontaktowy.
9. Sklep lub proces rezerwacji.
10. API.
11. Procesy aplikacji.
12. Bazę danych.
13. Pamięć RAM.
14. Procesor.
15. Miejsce na dysku.
16. Zadania cron.
17. Wysyłkę wiadomości.
18. Kopie zapasowe.
19. Błędy bezpieczeństwa.
20. Jasno określoną reakcję na alert.

Podsumowanie

Dobry monitoring strony internetowej 24/7 nie powinien ograniczać się do pytania:

**„Czy strona główna się otwiera?”**

Powinien również sprawdzać:

• czy serwer odpowiada prawidłowo,
• czy strona nie zwalnia,
• czy SSL jest ważny,
• czy formularze przyjmują zgłoszenia,
• czy sklep obsługuje zakupy,
• czy API działa,
• czy procesy są aktywne,
• czy backup rzeczywiście się wykonuje.

Monitoring jest najbardziej wartościowy wtedy, gdy jest połączony z procedurą działania i osobą odpowiedzialną za reakcję.

Samo wykrycie awarii nie wystarczy.

Firma potrzebuje jeszcze kogoś, kto wie, co sprawdzić i jak przywrócić stronę bez tworzenia kolejnych problemów.

Nie wiesz, czy Twoja strona jest prawidłowo monitorowana?

Skontaktuj się z HeatLogic. Sprawdzimy najważniejsze elementy serwisu, dobierzemy zakres monitoringu i wskażemy, które funkcje powinny być kontrolowane w Twoim przypadku.