Monitoring Dostępności i Uptime
RankVoyager regularnie odpytuje Twoją stronę i mierzy dostępność, czas odpowiedzi oraz poprawność zwracanych odpowiedzi HTTP. Każda anomalia generuje alert i jest zapisywana w historii incydentów.
Jak działają testy dostępności?
W każdym interwale system wysyła żądanie GET pod skonfigurowany adres URL i analizuje odpowiedź.
Sprawdzamy trzy rzeczy:
- Kod statusu HTTP - czy strona odpowiada oczekiwanym kodem (domyślnie
200) - Czas odpowiedzi - czas od wysłania żądania do otrzymania pełnych nagłówków odpowiedzi (TTFB)
- Dostępność treści - opcjonalnie: sprawdzenie czy odpowiedź zawiera określony fragment tekstu (content check)
Interwały skanowania
| Plan | Dostępny interwał | Domyślny |
|---|---|---|
| Basic (darmowy) | 60 minut | 60 min |
| Voyager Pro | 5, 10, 15, 30 minut | 5 min |
Interwał możesz zmienić w każdej chwili w Ustawienia strony → Monitoring → Interwał. Zmiana wchodzi w życie natychmiast.
Metryki i wskaźniki
Uptime %
Procentowy udział czasu, w którym strona była dostępna (odpowiadała poprawnym kodem HTTP), obliczany za wybrany okres (24h, 7 dni, 30 dni, 90 dni). Wzór:
Uptime % = (liczba udanych testów / łączna liczba testów) × 100
Za nieudany test uważa się: brak odpowiedzi (timeout), odpowiedź z kodem 5xx,
lub odpowiedź z innym niż oczekiwany kod jeśli skonfigurowano warunek.
Czas odpowiedzi (Response Time)
Mierzony w milisekundach - czas od momentu wysłania żądania HTTP do otrzymania pierwszego bajtu odpowiedzi (TTFB - Time to First Byte). Nie jest to czas pełnego załadowania strony w przeglądarce.
| Czas odpowiedzi | Ocena | Sugerowana akcja |
|---|---|---|
< 200ms | Doskonały | Brak |
200–500ms | Dobry | Monitoruj trendy |
500ms–1s | Wymaga uwagi | Zbadaj serwer, cache |
> 1s | Krytyczny | Zoptymalizuj natychmiast |
Kody statusu HTTP
Rozumiemy i klasyfikujemy wszystkie standardowe kody HTTP:
| Zakres kodów | Znaczenie | Traktowane jako |
|---|---|---|
2xx | Sukces (200 OK, 204 No Content…) | ✅ Dostępna |
301, 302 | Przekierowanie | ✅ Dostępna (śledzimy cel) |
4xx | Błąd klienta (404, 403, 429…) | ⚠️ Ostrzeżenie |
5xx | Błąd serwera (500, 502, 503…) | 🔴 Niedostępna |
| Timeout | Brak odpowiedzi w ciągu 15s | 🔴 Niedostępna |
Historia incydentów
Każdy test, który zakończy się statusem niedostępna lub ostrzeżenie, jest rejestrowany jako incydent. Historia incydentów zawiera:
- Datę i godzinę wystąpienia problemu
- Czas trwania incydentu
- Kod HTTP lub typ błędu
- Średni czas odpowiedzi podczas zdarzenia
- Informację o tym, kiedy strona wróciła do normy
Historia jest przechowywana przez 7 dni (plan darmowy) lub 90 dni (Pro).
Konfiguracja alertu dla niedostępności
Domyślnie alert o niedostępności jest wysyłany po pierwszym nieudanym teście. Możesz zmienić ten próg, żeby unikać fałszywych alarmów przy chwilowych mikrosprzerwach.
- Po 1 niepowodzeniu - reakcja natychmiastowa, możliwe fałszywe alarmy
- Po 2 niepowodzeniach z rzędu - dobry balans dla większości stron
- Po 3 niepowodzeniach z rzędu - mniej alarmów, ale wolniejsza reakcja
Content check - sprawdzanie zawartości odpowiedzi
Możesz skonfigurować dodatkowy warunek sukcesu: czy odpowiedź HTTP zawiera określony fragment tekstu.
Jest to przydatne gdy strona zwraca 200 OK, ale wyświetla stronę błędu (np. "Maintenance mode").
Ustaw to w Ustawienia strony → Monitoring → Content check → Wymagany tekst.
Przykład: RankVoyager, Strona główna, <title>.