Monitorowanie dostępności strony internetowej polega na wysyłaniu do niej zapytań według stałego harmonogramu i sprawdzaniu odpowiedzi. Jeśli odpowiedź jest błędna, powolna albo w ogóle jej nie ma, dostajesz alert. Brzmi prosto i takie właśnie jest. Wartość tkwi w szczegółach: jak często sprawdzasz, co uznajesz za błąd, jak błąd jest potwierdzany i jak szybko dowiaduje się o nim właściwa osoba.
Uptimecheck wykonuje testy HTTP(S), ping i portów co 1, 2, 5, 10, 15 lub 30 minut albo co godzinę. Każdy test zapisuje kod statusu i czas odpowiedzi, więc widzisz zarówno awarie, jak i okresy spowolnień. Jeśli chcesz najpierw poznać podstawy, przeczytaj, czym jest monitorowanie dostępności i dlaczego ma znaczenie.
Rodzaje testów
HTTP(S): odpytuj URL metodą GET, POST lub inną, wysyłaj własne nagłówki i treść żądania, a w odpowiedzi sprawdzaj kod statusu, słowo kluczowe lub pola JSON.Ping: sprawdź, czy host odpowiada w sieci, wraz z czasem odpowiedzi (round-trip).Port: sprawdź, czy usługa, np. serwer pocztowy albo nasłuchująca baza danych, przyjmuje połączenia.
Do ścieżek obejmujących kilka stron, takich jak logowanie czy finalizacja zakupu, użyj monitorowania procesów.
Dlaczego sprawdzać co minutę i to dwa razy
Przestój kosztuje z każdą minutą. Jeśli Twój checkout o 03:12 zwraca 503, a nikt tego nie zauważy aż do pierwszego zgłoszenia do supportu, tracisz godziny zamiast minut. Nasz poradnik o kosztach przestoju strony przelicza to krok po kroku.
Uptimecheck sprawdza ze Sztokholmu, Londynu i Nowego Jorku i potwierdza każdy błąd z drugiej lokalizacji, zanim otworzy incydent. To ogranicza fałszywe alarmy wywołane pojedynczym zgubionym żądaniem czy krótką czkawką sieci, a prawdziwa awaria i tak dociera do Ciebie w ciągu minuty lub dwóch. Nasz poradnik o ograniczaniu fałszywych alertów wyjaśnia, dlaczego to ważne.
Od nieudanego testu do naprawy
03:12: test northwind.shop/checkout zwraca 503.03:12: drugi test też się nie udaje. Otwiera się incydent z błędną odpowiedzią i zrzutem ekranu tego, co widzieli odwiedzający.03:13: dyżurny programista dostaje powiadomienie push na telefon, a kanał zespołu otrzymuje szczegóły w Slacku.03:19: testy znów przechodzą. Wychodzi powiadomienie o przywróceniu działania z łącznym czasem przestoju.
Alerty trafiają na e-mail, Slacka, Microsoft Teams, Discorda, Google Chat, Mattermost, Telegram, PagerDuty, ntfy, Pushover, webhooki i jako powiadomienia push na telefon, w każdym planie. Zobacz alerty i powiadomienia, aby poznać routing i eskalację, oraz zarządzanie incydentami, aby dowiedzieć się, co dzieje się po alercie. Połącz monitorowanie ze stroną statusu, aby klienci wiedzieli, co się dzieje, bez zakładania zgłoszenia.
Czasy odpowiedzi z podziałem na fazy
Każdy test HTTP zapisuje czas odpowiedzi z podziałem na DNS, połączenie, TLS, serwer i pobieranie. Wolna faza serwera wskazuje na aplikację, a wolny DNS lub TLS na infrastrukturę. Wykresy pokazują medianę, 95. percentyl i średnią, więc powolny ogon nie chowa się za dobrą średnią. Przeczytaj więcej o czasie odpowiedzi strony.
Ustaw limit, np. 2000 ms, a dostaniesz alert o spowolnieniu, gdy trzy testy z rzędu będą wolniejsze, i kolejny, gdy strona znów przyspieszy. Czas spowolnienia nie liczy się jako przestój.
Na stronie monitora widać jego ostatnie testy. Trzy lub więcej takich samych testów z rzędu zwija się w jeden wiersz, np. „OK · 200 × 18” z zakresem czasów odpowiedzi, który można rozwinąć, aby zobaczyć każdy test. Błąd nigdy nie zostaje zwinięty razem z udanymi testami, a drugi test potwierdzający błąd ma własny wiersz. Jeśli monitor, który nie jest wstrzymany, nie był sprawdzany przez dwukrotność swojego interwału, strona pokazuje „Brak aktualnych danych” z czasem ostatniego testu, więc stary status nigdy nie udaje bieżącego.
Sprawdź, czy strona naprawdę działa
Strona może odpowiadać kodem 200, a mimo to nie działać: pusta lista produktów, komunikat o błędzie, strona przerwy technicznej. Dodaj warunki odpowiedzi, które muszą być spełnione jednocześnie:
Oczekiwany status: kody lub zakresy, np. 200-299 albo 200,301.Słowo kluczowe: tekst, który strona musi zawierać lub którego nie może zawierać, np. „Dodaj do koszyka”.JSON i nagłówki: dla API pole takie jak $.status równe ok albo nagłówek, który musi być obecny.
Monitory HTTPS odczytują też certyfikat i przypominają o nim przed wygaśnięciem. Zobacz monitorowanie SSL.
Skonfiguruj pierwszy monitor
Dodaj URL, wybierz rodzaj testu, określ, jaka odpowiedź jest prawidłowa, i wybierz kanały alertów. „Testowe żądanie” pokazuje odpowiedź przed zapisaniem, a pierwszy test rusza od razu. Większość zespołów zaczyna od trzech monitorów: strony głównej, najważniejszej strony konwersji (checkout, rejestracja lub logowanie) i głównego endpointu API. Przechodzisz z UptimeRobot, Better Stack, Pingdom lub StatusCake? Zaimportuj monitory wraz z ustawieniami i przejrzyj każdy z nich, zanim cokolwiek zostanie utworzone.
Co liczy się jako awaria
Test kończy się błędem, gdy żądanie przekroczy limit czasu, połączenie zostanie odrzucone, certyfikat jest nieważny, kod statusu jest inny niż oczekiwany albo warunek odpowiedzi nie jest spełniony. Dostępność to odsetek czasu bez potwierdzonej awarii, a okna serwisowe się do niej nie wliczają. Raporty pokazują dostępność każdego monitora za dowolny okres na tle celu SLA, z eksportem do CSV.
Plany zaczynają się od 9 € miesięcznie przy płatności rocznej lub 12 € przy płatności miesięcznej, bez VAT, z testami co minutę w każdym płatnym planie. Za darmo możesz mieć 5 monitorów sprawdzanych co 5 minut. Porównaj liczbę monitorów, stron statusu i historię (1, 2 lub 3 lata) w cenniku, rozejrzyj się w demo na żywo bez rejestracji albo rozpocznij 14-dniowy darmowy okres próbny bez karty.