Stronę internetową możesz monitorować za darmo na cztery sposoby: korzystając z darmowego planu usługi monitorującej, uruchamiając mały skrypt na serwerze, który już masz, ustawiając zaplanowany workflow w usłudze CI, takiej jak GitHub Actions, albo sięgając po darmowe jednorazowe narzędzia, gdy coś już wygląda podejrzanie. W przypadku strony prywatnej czy projektu pobocznego to często wystarczy. Za monitoring warto zapłacić, gdy przestój kosztuje Cię pieniądze lub reputację, gdy musisz wiedzieć o awarii w ciągu minuty czy dwóch albo gdy trzeba obudzić i informować na bieżąco więcej niż jedną osobę.
Ten poradnik omawia każdą darmową opcję: w czym się sprawdza, czego po cichu nie zauważa i jak poznać, że już z niej wyrosłeś.
Co musi robić monitoring strony
Niezależnie od tego, czego używasz, darmowego czy płatnego, oceniaj to pod kątem czterech zadań. Jeśli brakuje choć jednego, nie masz jeszcze monitoringu, tylko nadzieję.
Regularne sprawdzanie z zewnątrz. Test wykonany z tego samego serwera, na którym działa strona, może przejść, choć odwiedzający nie mogą się połączyć. Interwał to najdłuższy czas, przez jaki możesz nie wiedzieć o awarii.
Jasna definicja awarii. Przekroczony limit czasu, odrzucone połączenie, błąd 5xx, nieważny certyfikat albo strona, która odpowiada kodem 200, ale wyświetla błąd. Szczegóły znajdziesz w artykule o tym, czym jest monitorowanie dostępności.
Dotarcie do człowieka. Alert, który o 03:00 trafia do folderu spam, nie jest alertem. Musi przyjść tam, gdzie naprawdę zaglądasz, a po nim powinno przyjść powiadomienie o przywróceniu działania.
Historia. Kiedy strona przestała działać, na jak długo i jak często to się zdarza? Bez historii nie odpowiesz klientowi, nie sprawdzisz SLA dostawcy hostingu i nie dostrzeżesz powtarzającego się wzorca.
Opcja 1: darmowy plan usługi monitorującej
Wiele usług monitorujących oferuje darmowy plan i to najszybszy sposób, by pokryć wszystkie cztery zadania dla kilku adresów URL. Limity różnią się między usługami i zmieniają się z czasem, więc czytaj aktualną stronę z planami i regulamin, a nie artykuł porównawczy. Warto zadać takie pytania:
Jak często sprawdza? Darmowe plany często sprawdzają rzadziej niż płatne. Co 5 minut oznacza, że awaria może trwać nawet 5 minut, zanim pierwszy test się nie powiedzie.
Czy błąd jest potwierdzany przed alertem? Drugi test z tej samej lub innej lokalizacji odfiltrowuje pojedyncze zgubione żądanie. Bez tego licz się z fałszywymi alertami.
Jakie kanały alertów są dostępne? Tylko e-mail czy także czat i powiadomienia push na telefonie?
Czy sprawdza treść? Sam kod statusu nie wychwyci strony, która się ładuje, ale nie działa. Szukaj sprawdzania słów kluczowych lub odpowiedzi.
Jak długo przechowywana jest historia i czy dozwolone jest użycie komercyjne? Niektóre darmowe plany są przeznaczone wyłącznie do projektów prywatnych.
Opcja 2: skrypt na serwerze, który już masz
Jeśli masz serwer lub VPS w innym miejscu niż ten, na którym działa strona, jedna linia w crontabie da Ci podstawowy test co 5 minut:
*/5 * * * * curl -fsS -m 10 -o /dev/null https://example.com/ || echo „example.com failed at $(date -u)” | mail -s „Site down” you@example.com
-f sprawia, że curl zwraca błąd przy błędach HTTP, -m 10 przerywa po 10 sekundach, a e-mail wychodzi tylko wtedy, gdy żądanie się nie powiedzie. Nic to nie kosztuje i masz kontrolę nad każdym szczegółem. Ma to jednak realne luki:
Nikt nie pilnuje pilnującego. Jeśli ten serwer przestanie działać albo zepsuje się na nim wysyłka poczty, testy ustają i nic do Ciebie nie dociera. Cisza wygląda dokładnie tak samo jak sprawna strona.
Poczta z serwera często trafia do spamu, chyba że domena nadawcy ma skonfigurowane SPF, DKIM i DMARC. Nasz poradnik o SPF, DKIM i DMARC wyjaśnia dlaczego.
Każdy błąd to alert i dostajesz go co 5 minut przez cały czas trwania awarii, ale żadnego powiadomienia o przywróceniu działania.
Brak historii. Jeśli nie zapisujesz każdego wyniku i nie budujesz raportu, nie powiesz, jaka była dostępność w zeszłym miesiącu.
Nigdy nie uruchamiaj testu na tym samym serwerze co strona. Serwer, do którego nie da się dotrzeć z internetu, zwykle wciąż może połączyć się sam ze sobą.
Opcja 3: zaplanowany workflow CI
Nie masz zapasowego serwera? Ten sam test może uruchamiać zaplanowany workflow w GitHub Actions. Nieudany krok oznacza nieudane uruchomienie, a GitHub wysyła Ci powiadomienie:
name: Site check
on:
schedule:
– cron: '7,22,37,52 * * * *’
jobs:
check:
runs-on: ubuntu-latest
steps:
– run: curl -fsS -m 10 -o /dev/null https://example.com/
To działa, ale z ograniczeniami, które GitHub opisuje w dokumentacji zdarzenia schedule:
Najkrótszy interwał to raz na 5 minut.
Zaplanowane uruchomienia mogą się opóźniać, gdy GitHub Actions jest obciążony, zwłaszcza na początku każdej godziny, a niektóre zadania w kolejce mogą zostać pominięte. Dlatego przykład unika minuty 0.
W publicznym repozytorium zaplanowane workflow są wyłączane po 60 dniach bez aktywności w repozytorium.
Powiadomienia trafiają do użytkownika, który ostatni zmienił harmonogram cron w pliku workflow, a nie do zespołu.
Workflow to dobre rozwiązanie tymczasowe dla projektu pobocznego. Jako monitoring czegoś, za co ludzie płacą, alert, który może przyjść z opóźnieniem albo wcale, jest słabym ogniwem. Narzędzie do wyrażeń cron pokazuje, kiedy taki harmonogram jak powyższy faktycznie się uruchamia.
Opcja 4: darmowe narzędzia na wypadek, gdy coś wygląda podejrzanie
Jednorazowe narzędzia niczego nie pilnują, ale w kilka sekund odpowiadają na pierwsze pytania podczas incydentu. Wszystkie są darmowe i nie wymagają konta:
Is it down? jednorazowo sprawdza dowolną stronę z naszego serwera, dzięki czemu odróżnisz „nie działa u nikogo” od „nie działa tylko u mnie”.
Sprawdzanie SSL pokazuje, kiedy wygasa certyfikat, kto go wystawił i pełny łańcuch certyfikatów.
Sprawdzanie wygaśnięcia domeny odczytuje z rejestru datę wygaśnięcia i rejestratora.
Wyszukiwanie DNS i sprawdzanie SPF, DKIM i DMARC pokazują, co Twoja domena publikuje w tej chwili.
Narzędzia te są uzupełnieniem, a nie zamiennikiem: sprawdzają tylko wtedy, gdy o to poprosisz, a prosisz dopiero wtedy, gdy już podejrzewasz problem. Lista kontrolna na wypadek awarii strony pokazuje, gdzie pasuje każde z nich.
Dwie daty wygaśnięcia, o których zapominają darmowe rozwiązania
Awariom spowodowanym wygasłymi certyfikatami i domenami najłatwiej zapobiec, a zwykły test „czy działa?” zauważa je dopiero po fakcie.
Certyfikaty. Let’s Encrypt przestał wysyłać e-maile o wygaśnięciu 4 czerwca 2025 r., więc jeśli Twoje zadanie odnawiania się zepsuje, nikt Ci o tym nie powie. Certyfikaty mają też coraz krótszy okres ważności, co oznacza więcej odnowień, które mogą się nie udać; zobacz, co oznacza skracanie okresu ważności certyfikatów.
Domeny. Przypomnienia o odnowieniu trafiają na adres e-mail przypisany do konta u rejestratora, który często jest stary albo należy do kogoś, kto już odszedł z firmy. Włącz automatyczne odnawianie i sprawdź, czy zapisana karta jest ważna.
Kiedy czas zapłacić
Darmowy monitoring wystarcza, dopóki awaria, o której dowiadujesz się późno, jest tylko irytująca, a nie oznacza strat. Oto sygnały, że już tak nie jest:
Strona zarabia z minuty na minutę. Sklep, system rezerwacji albo produkt SaaS. Policz to w kalkulatorze kosztów przestoju; jeśli godzina przestoju kosztuje więcej niż rok monitoringu, decyzja jest prosta.
Obiecujesz konkretny poziom dostępności. 99,9% pozwala na 43 minuty i 49 sekund przestoju w miesiącu, jak pokazuje kalkulator dostępności. Przy interwale 5 minut samo wykrycie awarii może zużyć dużą część tego limitu.
Zaangażowana jest więcej niż jedna osoba. Alerty muszą docierać do osoby na dyżurze, eskalować, gdy nikt nie reaguje, i trafiać na czat zespołu.
Klienci pytają „czy to tylko u mnie?”. Strona statusu aktualizowana na podstawie Twoich testów odpowiada im, zanim założą zgłoszenie.
Opiekujesz się stronami klientów. Potrzebujesz raportów, które pokazują, co się stało i kiedy, bez ręcznego ich przygotowywania.
Najważniejsza nie jest strona główna. Koszyk, logowanie, API czy nocna kopia zapasowa wymagają testów, z którymi linia z curl sobie nie radzi: wieloetapowych ścieżek, sprawdzania JSON i heartbeatów.
Co zyskujesz, płacąc za Uptimecheck
Uptimecheck ma darmowy plan: każdy nowy obszar roboczy zaczyna od 14-dniowego bezpłatnego okresu próbnego planu Professional, bez podawania karty, a potem przechodzi na plan Free, chyba że wybierzesz inny plan. Free sprawdza 5 monitorów co 5 minut, z 1 stroną statusu i maksymalnie 3 kanałami alertów, takimi jak e-mail, Slack czy Microsoft Teams, a użycie komercyjne jest dozwolone. Każdy płatny plan obejmuje:
Testy dostępności co minutę ze Sztokholmu, Londynu i Nowego Jorku, przy czym każdy błąd jest potwierdzany z drugiej lokalizacji przed wysłaniem alertu, a odpowiedź można sprawdzać pod kątem słów kluczowych, JSON i nagłówków.
Alerty przez e-mail, Slack, Microsoft Teams, Discord, Google Chat, Mattermost, Telegram, PagerDuty, ntfy, Pushover, webhooki i powiadomienia push na telefonie, z powiadomieniem o przywróceniu działania, gdy strona znów działa.
Przypomnienia o wygaśnięciu SSL i domeny, heartbeaty dla zadań cron oraz strony statusu, które aktualizują się same.
Historię dostępności, czasów odpowiedzi i incydentów przez 1, 2 lub 3 lata, zależnie od planu.
Plany kosztują 12 €, 39 € lub 92 € miesięcznie przy płatności co miesiąc albo 9 €, 29 € lub 69 € miesięcznie przy płatności rocznej, netto (bez VAT), a sprzedaje je Link (Stripe), nasz reseller. Start obejmuje 15 monitorów dostępności, Professional 100, a Business 250. Porównaj wszystko na stronie z cennikiem albo najpierw rozejrzyj się w demo na żywo.
Zacznij za darmo i przejdź wyżej, gdy strona zacznie mieć znaczenie. Wypróbuj Uptimecheck za darmo przez 14 dni, bez karty kredytowej.