FAQ - najczęściej zadawane pytania

To najmniejsza część tego, co robimy. Do wyboru są cztery typy monitorów:

• HTTP/HTTPS - pobieramy adres i oceniamy odpowiedź serwera. Klasyczny monitoring dostępności.
• Port (TCP) - otwieramy połączenie na wskazany port. Do wszystkiego, co nie jest stroną WWW: serwer pocztowy, NAS, baza danych.
• DNS - pytamy resolver o rekord domeny i porównujemy odpowiedź z tym, czego oczekujesz.
• API (JSON) - porównujemy kształt odpowiedzi endpointu z zapisanym wzorcem.

Do monitora HTTP możesz dodatkowo włączyć sprawdzanie treści strony, monitoring certyfikatu SSL oraz codzienny audyt kondycji, który wykrywa regresje po zmianach na stronie. To ostatnie jest tym, co odróżnia nas od zwykłego pingera.

Tak, są dwie darmowe drogi:

• Plan Free - bezterminowy, z ograniczoną liczbą monitorów i bez części dodatkowych funkcji. Nie wymaga płatności ani deklaracji, że kiedyś zapłacisz.
• 30 dni testów dowolnego płatnego planu - żeby sprawdzić funkcje, których w planie Free nie ma (np. audyt kondycji).

Po zakończeniu okresu testowego monitory nie znikają. Konto przechodzi w stan, w którym sprawdzenia są wstrzymane do momentu wyboru planu, a dane historyczne czekają. Aktualne limity i ceny znajdziesz na stronie z cennikiem.

Liczba monitorów zależy od planu - dokładne wartości są w cenniku i w zakładce rozliczeń, gdzie widzisz też bieżące zużycie („wykorzystane X z Y").

Limitu nie da się przekroczyć przypadkiem: przy próbie dodania monitora ponad limit dostaniesz komunikat zamiast cichego naliczenia opłaty. Masz wtedy dwie opcje - usunąć monitor, którego już nie potrzebujesz, albo przejść na wyższy plan.

Część funkcji ma osobne limity, niezależne od liczby monitorów: monitoring treści i monitory API są przydzielane jako pula w ramach planu, bo kosztują znacznie więcej niż zwykłe sprawdzenie dostępności.

To zależy od interwału, który sam ustawiasz dla każdego monitora osobno - od jednej minuty do dwunastu godzin. Dla stron produkcyjnych typowy wybór to 1 lub 5 minut.

Do czasu sprawdzenia dolicz krótkie potwierdzenie: zanim uznamy stronę za niedostępną, ponawiamy sprawdzenie. Dzięki temu pojedyncze mignięcie sieci nie budzi Cię w nocy. W praktyce alert o realnej awarii dostajesz w ciągu 1-3 minut od jej wystąpienia przy interwale minutowym.

Alert o powrocie strony wysyłamy tak samo szybko, więc wiesz nie tylko, że coś padło, ale też że już wstało.

Mamy trzy kanały i możesz włączyć dowolną ich kombinację:

• E-mail - podstawowy, działa zawsze.
• Powiadomienia push w przeglądarce - najszybsze przy pracy przy komputerze.
• Powiadomienia na telefon przez ntfy - darmowa aplikacja na Androida i iOS. W profilu generujesz własny, trudny do zgadnięcia temat i subskrybujesz go w aplikacji.

SMS-ów nie wysyłamy i na razie tego nie planujemy. Powiadomienie przez ntfy dociera równie szybko, nie kosztuje ani grosza i pozwala nam nie doliczać opłat za pakiety wiadomości.

Kanały ustawiasz raz w profilu, a dla każdego monitora osobno decydujesz, o jakich zdarzeniach chcesz być informowany: niedostępność i powrót, wygasający certyfikat, pogorszenie kondycji strony.

Nie instalujesz niczego. Nie ma wtyczki, skryptu ani agenta do wgrania na serwer - wystarczy podać adres. Wszystko dzieje się z zewnątrz, dokładnie tak, jak robi to przeglądarka odwiedzającego.

Obciążenie jest znikome. Zwykłe sprawdzenie dostępności to jedno lekkie zapytanie HTTP. Monitoring treści pobiera stronę w całości, ale ma odgórny limit rozmiaru pobieranych danych, a audyt kondycji uruchamiamy raz dziennie.

Dla porównania: jeden pojedynczy użytkownik przeglądający Twoją stronę generuje zwykle większy ruch niż nasz monitoring przez cały dzień.

To najczęstsze zgłoszenie i prawie zawsze jest za tym jedna z poniższych przyczyn:

1. Firewall, WAF lub Cloudflare blokuje nasze zapytania. Twoja przeglądarka ma ciasteczka i historię, nasz monitoring nie - dla zabezpieczeń wygląda jak bot. Rozwiązanie: dodaj nasze adresy IP do białej listy (patrz pytanie niżej).
2. Błąd certyfikatu SSL. Wygasły, samopodpisany, niepasujący do adresu. Przeglądarka pokaże ostrzeżenie, które można kliknąć, monitoring nie klika - i traktuje to jako niedostępność. W szczegółach monitora zobaczysz dokładny powód.
3. Przekroczony limit czasu odpowiedzi. Strona odpowiada, ale wolniej niż ustawiony timeout. Sprawdź czas odpowiedzi na wykresie - jeśli wzrósł, to nie fałszywy alarm, tylko realny problem z wydajnością.
4. Blokada geograficzna albo rate limiting na serwerze, który uznaje regularne zapytania za podejrzane.
5. Cache przeglądarki. U Ciebie ładuje się wersja z cache'u, my za każdym razem pobieramy stronę na świeżo. Sprawdź w trybie prywatnym.

W szczegółach monitora, w historii sprawdzeń, zawsze widać konkretny powód (kod odpowiedzi, błąd certyfikatu, timeout) - to jest pierwsze miejsce, do którego warto zajrzeć.

Adresy, z których wysyłamy zapytania, są jawne i znajdziesz je w aplikacji przy ustawieniach monitora. Warto dodać je do białej listy, jeśli:

• masz firewall, WAF albo ModSecurity, które blokują powtarzalny ruch,
• korzystasz z Cloudflare lub podobnej usługi z agresywnym trybem ochrony,
• masz wtyczkę bezpieczeństwa blokującą IP po serii zapytań (to częsty przypadek przy WordPressie),
• monitorujesz zasób zamknięty na wybrane adresy.

Bez tego pierwszy fałszywy alarm pojawia się zwykle w ciągu kilku dni od dodania monitora - a to nie jest awaria strony, tylko skuteczne zabezpieczenie.

Po kolei, od najczęstszej przyczyny:

1. Kanały powiadomień w profilu. Alerty wysyłamy tylko na kanały włączone w zakładce „Mój profil". Jeśli nie masz włączonego żadnego, żaden alert nie wyjdzie - pokazujemy wtedy ostrzeżenie przy ustawieniach alertów.
2. Alerty przy samym monitorze. Kanały to jedno, a zgoda na konkretne zdarzenia to drugie. Sprawdź, czy przy danym monitorze zaznaczone są alerty dostępności.
3. Powiadomienia push zablokowane przez przeglądarkę. Jeśli kiedyś kliknąłeś „Blokuj", przeglądarka nie zapyta drugi raz. Kliknij kłódkę na pasku adresu, zmień uprawnienie dla powiadomień na „Zezwalaj" i odśwież stronę.
4. ntfy z niezgodnym tematem. Temat w aplikacji ntfy musi być identyczny z tym z profilu, a serwer ten sam. Jest przycisk „Wyślij test" - to najszybszy sposób sprawdzenia.
5. E-mail w spamie. Zdarza się przy pierwszej wiadomości. Dodaj nasz adres do kontaktów.
6. Monitor jest wstrzymany. Wstrzymany monitor nie jest sprawdzany, więc nie ma z czego wygenerować alertu.

Monitoring dostępności odpowiada na pytanie „czy strona działa". Kondycja odpowiada na pytanie „czy działa tak samo dobrze jak wczoraj".

Raz dziennie robimy audyt strony w pięciu kategoriach: dostępność, bezpieczeństwo, SEO, dobre praktyki i wydajność (na podstawie Core Web Vitals z realnych pomiarów użytkowników Chrome). Wynik porównujemy z poprzednim audytem i pokazujemy różnicę.

Najważniejsze jest to, że nie dostajesz kolejnego raportu ze stoma rzeczami do poprawy. Historia jest prowadzona jako dziennik zmian: wpis powstaje wtedy, gdy coś się zepsuło, naprawiło albo zmieniło, plus wpis kontrolny raz na tydzień. Wykrywamy m.in. nagłe pojawienie się noindex, zniknięcie nagłówków bezpieczeństwa, mixed content, wydłużony łańcuch przekierowań, zmianę tytułu strony czy usunięty nagłówek Cache-Control.

Przy każdej wykrytej regresji pokazujemy kontekst z tego samego okna czasowego: czy zmieniła się treść strony, czy zniknęły nagłówki, czy zmienił się serwer, o ile urósł HTML. To zwykle wystarcza, żeby wskazać przyczynę.

Alerty regresji wyzwala wynik samej strony, liczony bez danych Core Web Vitals - te potrafią zmienić się bez żadnej zmiany po Twojej stronie i nie chcemy Cię z tego powodu budzić.

Włączasz go przy monitorze HTTP jednym przełącznikiem. Od tego momentu:

• sprawdzamy datę ważności certyfikatu i pokazujemy ją w szczegółach monitora,
• ostrzegamy z wyprzedzeniem 30, 14 i 7 dni przed wygaśnięciem,
• błąd certyfikatu (wygasły, niepasujący do adresu, samopodpisany, niezaufany) oznacza stronę jako niedostępną, bo dla odwiedzającego jest to właśnie awaria.

Jeśli świadomie używasz certyfikatu samopodpisanego, np. w środowisku wewnętrznym, możesz włączyć opcję ignorowania błędów certyfikatu. Strona nie będzie wtedy z tego powodu oznaczana jako niedostępna, a datę ważności nadal monitorujemy. Pamiętaj tylko, że przeglądarki i tak pokażą odwiedzającym ostrzeżenie.

Dodajesz monitor typu DNS, wskazujesz nazwę i typ rekordu (A, AAAA, CNAME, MX, NS, TXT, CAA, SRV), a następnie wpisujesz wartości, których oczekujesz. My pytamy resolver i porównujemy odpowiedź.

Do wyboru są trzy tryby dopasowania:

• zawiera - wszystkie zadeklarowane wartości muszą być w odpowiedzi, dodatkowe rekordy są w porządku. Bezpieczny domyślny wybór.
• dokładnie - odpowiedź musi być dokładnie taka, jak zadeklarowana. To jedyny tryb, który wykryje rekord dodany przez kogoś innego, czyli tak wygląda ingerencja w strefę.
• istnieje - rekord ma po prostu być i nie być pusty, bez porównywania wartości.

Najczęstsze zastosowania: rekord A, żeby wiedzieć, że domena wskazuje na właściwy serwer (przydatne przy migracji), rekord MX, bo zniknięcie poczty nie objawia się niczym widocznym na stronie, oraz rekord TXT ze SPF-em, żeby Twoje maile nie zaczęły wpadać do spamu.

Gdy coś się nie zgadza, w szczegółach monitora pokazujemy wprost, czego oczekiwaliśmy i co odpowiedział resolver.

Tak, służy do tego monitor typu port (TCP). Podajesz host i numer portu, a my otwieramy połączenie i mierzymy czas jego nawiązania. Połączenie doszło do skutku - usługa działa.

Ma to jedną praktyczną przewagę nad sprawdzaniem panelu przez HTTP: interfejsy webowe takich urządzeń potrafią budzić się wolno i generują fałszywe alarmy, mimo że urządzenie cały czas jest dostępne. Port odpowiada natychmiast.

Jeśli monitorowane urządzenie stoi na wolnym łączu i mimo to zdarzają się przekłamania, włącz opcję obniżonej czułości - monitor daje wtedy hostowi więcej czasu na odpowiedź, zanim uzna go za niedostępny.

To monitor dla endpointów zwracających JSON. Przy jego tworzeniu zapisujemy kształt odpowiedzi: jakie pola w niej są i jakiego są typu. Przy każdym sprawdzeniu porównujemy aktualną odpowiedź z tym wzorcem.

Kluczowe jest to, czego nie porównujemy: wartości. Zmieniony tytuł artykułu czy inna liczba w polu to nie jest incydent. Zniknięte pole albo zmieniony typ - jak najbardziej.

Łapie to awarię, której nie widać z zewnątrz: API odpowiada kodem 200, a aplikacja, która się nim żywi, przestaje działać. Typowo po aktualizacji modułu lub wtyczki.

Obsługujemy metody GET i POST (celowo nie PUT, PATCH ani DELETE - monitor pracuje latami i nie będzie modyfikował Twoich danych). Dla GraphQL-a wpisujesz samo zapytanie, a my opakowujemy je w poprawny JSON. Możesz też dodać proste warunki na wybrane pola, np. że ścieżka errors nie może istnieć - GraphQL potrafi odpowiadać dwusetką również wtedy, gdy backend leży.

Przy każdym monitorze jest opcja wstrzymania. Wstrzymany monitor nie jest sprawdzany i nie wyśle alertu.

Ważne: okno przerwy zapisujemy w historii i nie wliczamy go do statystyki uptime. Dzięki temu planowana przerwa techniczna nie psuje wyniku dostępności i nie musisz tłumaczyć w raporcie, skąd nagle 97%.

Na liście monitorów i na ekranie „Wymaga uwagi" wstrzymany monitor jest wyraźnie oznaczony razem z informacją, od kiedy trwa pauza - żeby nie zdarzyło się, że wstrzymałeś coś przed wdrożeniem i włączyłeś dopiero miesiąc później.

Zależy to od planu - dokładny okres przechowywania statystyk znajdziesz w cenniku przy każdym planie.

Niezależnie od tego zawsze masz do dyspozycji:

• oś dostępności z ostatnich 90 dni w szczegółach monitora,
• listę zdarzeń i incydentów z godzinami rozpoczęcia, czasem trwania i powodem,
• historię sprawdzeń,
• historię audytów kondycji z wykresem wyniku w czasie oraz wykresem czasu odpowiedzi dzień po dniu.

Po przejściu na wyższy plan dane zaczynają być przechowywane dłużej od momentu zmiany. Nie odzyskamy tego, co zostało już usunięte zgodnie z poprzednim planem.

Tak, służy do tego zakładka Zespół. Model jest prosty:

• Członek zespołu ma własne, niezależne konto - nie dzielicie się loginem, on nie widzi Twoich ustawień ani rozliczeń.
• Zapraszasz go po adresie e-mail konta, które już istnieje w systemie. Jego plan nie ma znaczenia, bo otrzymanie udostępnienia nic nie kosztuje.
• Udostępniasz mu wybrane monitory, nie wszystko naraz.
• Widzi statusy i statystyki udostępnionych monitorów i ustawia sobie własne alerty na własnych kanałach. Dzięki temu awaria budzi dwie osoby, a reaguje ta, która akurat może.
• Domyślnie może tylko przeglądać - niczego nie zmieni ani nie usunie. Jeśli potrzebujesz dać więcej, jest osobne uprawnienie edytora: pozwala zmieniać ustawienia udostępnionych monitorów, ale nie dodawać nowych ani usuwać istniejących.

Liczba miejsc w zespole zależy od planu. Wysłane, jeszcze nieprzyjęte zaproszenie również zajmuje miejsce.

Utwórz publiczną stronę statusów. Wybierasz, które monitory mają się na niej znaleźć, nadajesz jej nazwę i krótki opis, a dostajesz gotowy adres URL do przekazania.

Możesz ją zabezpieczyć hasłem, jeśli nie ma być dostępna dla każdego, kto zna link.

To rozwiązuje dwie rzeczy naraz: klient przestaje pytać „czy u was też nie działa", bo sprawdza sam, i widzi, że ktoś realnie pilnuje jego serwisów. Przy umowach utrzymaniowych to najprostszy dowód, że usługa jest świadczona.

Uwaga na sposób działania udostępniania: na stronie statusów lądują te monitory, które wybierzesz w danym momencie. Monitor dodany później nie pojawi się na niej automatycznie.

Trzy rzeczy, które warto zrobić od razu:

• Projekty. Grupujesz monitory, np. jeden projekt na klienta albo na środowisko. Strona główna, kluczowe podstrony, rekordy DNS i usługi jednego klienta widoczne na jednym ekranie.
• Dodawanie wielu adresów naraz. Przy zakładaniu monitoringu dla nowego serwisu wrzucasz kilkanaście adresów w jednym kroku zamiast klikać każdy osobno.
• Sensowne nazwy. Nazwa monitora pojawia się w alertach, więc „Sklep - koszyk" mówi o trzeciej w nocy znacznie więcej niż sam adres URL.

Do tego jest ekran „Wymaga uwagi", który pokazuje wyłącznie to, co wymaga reakcji: co leży, co wróciło, komu wygasa certyfikat. Przy większej liczbie monitorów to jedyny ekran, na który trzeba patrzeć codziennie.

Na razie nie. Wszystkie sprawdzenia wykonujemy z naszej domyślnej lokalizacji i nie ma opcji wskazania innego kraju czy regionu.

W praktyce dla większości zastosowań nie ma to znaczenia: awaria serwera, błąd aplikacji, wygasły certyfikat czy zmieniony rekord DNS wyglądają tak samo z każdego miejsca na świecie. Różnice widać głównie w czasie odpowiedzi, a ten mierzymy zawsze z tego samego punktu - i właśnie dlatego porównanie „dziś kontra Twój baseline" jest wiarygodne.

Wybór lokalizacji jest u nas w planach rozwoju. Jeśli jest to dla Ciebie istotne, napisz - takie zgłoszenia realnie wpływają na kolejność prac.

Plan zmieniasz w zakładce rozliczeń. Przejście na wyższy działa od razu i od razu odblokowuje limity oraz funkcje.

Przy przejściu na niższy plan nie kasujemy niczego po cichu. Zanim potwierdzisz zmianę, pokazujemy dokładną listę konsekwencji, na przykład:

• ile monitorów jest ponad limit nowego planu,
• ilu członków zespołu trzeba usunąć i ile udostępnień zostanie przez to cofniętych,
• które funkcje przestaną działać i przy ilu monitorach (monitoring certyfikatu, audyt kondycji, monitoring treści, monitory API).

Dopiero po zapoznaniu się z tą listą decydujesz. Monitory, które przekraczają limit, wskazujesz i usuwasz sam - nie wybieramy ich za Ciebie.

Logowanie odbywa się adresem e-mail i hasłem, a dodatkowo masz do dyspozycji:

• Weryfikację dwuetapową (2FA) opartą o aplikację z kodami jednorazowymi, np. Google Authenticator czy Aegis. Przy włączaniu dostajesz kody odzyskiwania na wypadek utraty telefonu i możesz je w każdej chwili wygenerować od nowa.
• Listę aktywnych sesji w profilu. Widzisz, gdzie jesteś zalogowany, i możesz zakończyć wybraną sesję zdalnie - przydatne po zalogowaniu się na cudzym komputerze.

Zmiana adresu e-mail wymaga potwierdzenia linkiem wysłanym na nowy adres, więc samo przejęcie zalogowanej przeglądarki nie wystarczy, żeby przejąć konto.

Przechowujemy tylko to, co jest potrzebne do świadczenia usługi: dane konta (adres e-mail, nazwa), konfigurację monitorów, wyniki sprawdzeń i historię zdarzeń oraz dane rozliczeniowe, jeśli korzystasz z planu płatnego. Szczegóły znajdziesz w polityce prywatności i w informacji o RODO.

Konto usuwasz sam, z poziomu profilu. Operacja jest dwuetapowa: wysyłamy kod potwierdzający na Twój adres e-mail i dopiero jego wpisanie kasuje konto. To zabezpieczenie przed przypadkowym i przed cudzym kliknięciem.

Usunięcie konta jest nieodwracalne. Znikają wszystkie Twoje monitory razem z historią sprawdzeń i audytów, a dostęp osób, którym udostępniałeś monitory, zostaje cofnięty. Konta członków zespołu pozostają nienaruszone - są niezależne i mają własne plany oraz własne strony.