Monitorowanie strony: uptime, alerty i budżet na dostępność

Wdrożyłem monitoring dla kilkudziesięciu stron – firmowych, sklepowych i blogowych. Powtarza się jeden wzorzec: awarie wykrywane po godzinach, alerty tonące w spamie i zero raportów dla właściciela. Ten post to kompletny, praktyczny system monitorowania, który możesz postawić w jeden wieczór – od prostego uptime checka po budżet na dostępność (SLO) i syntetyczne testy.

Dlaczego monitoring nie jest opcją

Strona, która leży, kosztuje trzy rzeczy naraz:

1. Ruch – każda godzina przestoju to utracone wejścia, które nie wrócą. Google nie odkłada sobie linku do przemyślenia.
2. Przychód – dla sklepu 1 godzina przerwy w godzinach szczytu to realna utrata sprzedaży, a nie teoretyczna.
3. Zaufanie – użytkownik, który dwa razy trafi na błąd 502, idzie do konkurencji. Badania pokazują, że 40% osób czeka maksymalnie 3 sekundy, a po nieudanym wejściu wraca mniej niż połowa.

Do tego dochodzi efekt SEO: długie serie błędów 5xx odczytane przez Googlebota mogą wpłynąć na indeksację i ranking. Monitoring nie sprawi, że awarie znikną, ale skraca czas reakcji z godzin do minut, a to zmienia wszystko.

Co monitorować: cztery warstwy

1. Uptime HTTP/HTTPS

Najprostsza i najważniejsza warstwa: czy serwer odpowiada poprawnym kodem. Monitoring wysyła żądanie co 1-5 minut z kilku lokalizacji i uznaje monitor za niedostępny, gdy kod odpowiedzi różni się od oczekiwanego (zwykle 200) lub czas odpowiedzi przekracza próg.

2. Certyfikat SSL

Certyfikat wygasły = przeglądarka blokuje stronę ostrzeżeniem. Wygaśnięcie SSL to jedna z najczęstszych “awarii”, które wcale nie są awariami infrastruktury. Monitor SSL ostrzega z 14-30 dniowym wyprzedzeniem – darmowy Let’s Encrypt i tak trzeba czasem odnowić ręcznie.

3. Wydajność (RUM i pomiary syntetyczne)

Sama dostępność nie wystarczy. Strona może być “dostępna” i ładować się 8 sekund. Pomiar syntetyczny sprawdza czasy odpowiedzi z wybranych lokalizacji, a RUM (Real User Monitoring) mierzy faktyczne doświadczenie użytkowników – LCP, INP, CLS. Zmiany po wdrożeniu są natychmiast widoczne w wykresach.

4. Krytyczne funkcje

Uptime check sprawdzi tylko, czy serwer żyje. Nie sprawdzi, czy działa formularz kontaktowy, logowanie czy płatność. Do tego służą syntetyczne testy – scenariusze przeglądarkowe odtwarzające ścieżkę użytkownika (więcej niżej).

Jak działa uptime check

Zanim kupisz narzędzia, sprawdź ręcznie, co mierzy twój serwer:

# Prosty check: kod odpowiedzi + całkowity czas
curl -s -o /dev/null -w "HTTP %{http_code} | %{time_total}s\n" \
  https://twojadomena.pl

# Z czasem TTFB i rozmiarem odpowiedzi
curl -s -o /dev/null -w "TTFB: %{time_starttransfer}s | Rozmiar: %{size_download}B\n" \
  https://twojadomena.pl

# Cron na serwerze: alert, gdy kod != 200
0 * * * * curl -fsS https://twojadomena.pl >/dev/null \
  || curl -fsS "https://api.uptimerobot.com/..." >/dev/null

Taki check w cronie to minimalna wersja monitoringu. W praktyce użyj gotowego narzędzia, bo dostaniesz sieć lokalizacji, historię i alerty.

UptimeRobot API: konfiguracja programowa

UptimeRobot ma darmowy plan z 50 monitorami i pełne REST API. Całą konfigurację da się wersjonować w repozytorium:

# Utwórz monitor HTTP z kluczem API (Settings → API Settings)
curl -s -X POST "https://api.uptimerobot.com/v2/newMonitor" \
  -d "api_key=u123456-xxxxxxxxxxxxxxxx" \
  -d "type=1" \
  -d "url=https://twojadomena.pl" \
  -d "friendly_name=Strona glowna" \
  -d "interval=60" \
  -d "alert_contacts=9876543210"

# Pobierz status wszystkich monitorów (2 = down)
curl -s -X POST "https://api.uptimerobot.com/v2/getMonitors" \
  -d "api_key=u123456-xxxxxxxxxxxxxxxx" \
  -d "format=json"

Ustaw też alert contact z eskalacją: e-mail dla zespołu, SMS lub push dla osoby na dyżurze. Bez tego alerty trafiają do nikogo.

Alerty: jak nie zignorować awarii

Najczęstszy błąd to 40 alertów dziennie od jednego monitora. Po godzinie ludzie wyciszają kanał i przestają reagować. Dobre alerting ma trzy cechy:

• Eskalacja – najpierw e-mail, po 15 minutach SMS/push, po 30 minutach telefon. Każdy kolejny poziom oznacza, że poprzedni nie zadziałał.
• Deduplikacja – jeden otwarty incydent = jeden alert, nie jeden na każdy check. Po potwierdzeniu awarii alerty milkną.
• Status page – automatycznie publikuj informację o awarii na publicznej stronie statusu (UptimeRobot, Statuspage, własna). Użytkownicy sprawdzają status zamiast pisać do supportu.

Sprawdź też, czy alerty faktycznie dochodzą: raz w miesiącu zamknij monitor testowy i zobacz, kto i jak reaguje.

Syntetyczne testy: scenariusze przeglądarkowe

Uptime check odpowie “200” nawet, gdy formularz na stronie rzuca błąd 500 po wysłaniu. Syntetyczny test odtwarza prawdziwą ścieżkę:

# Checkly / Playwright: test, który naprawdę wysyła formularz
npx checkly test --env=production

Przykładowy scenariusz (Checkly CLI):

import { test, expect } from '@playwright/test';

test('formularz kontaktowy dziala', async ({ page }) => {
  await page.goto('https://twojadomena.pl/kontakt');
  await page.fill('#email', 'test@example.com');
  await page.fill('#message', 'Test monitoringu');
  await page.click('button[type=submit]');
  await expect(page.locator('[aria-live]')).toContainText('Wysłano');
});

Taki test uruchamiany co 10 minut z kilku lokalizacji wykrywa awarie funkcjonalne, których klasyczny monitor nie zobaczy. Dla sklepu dodaj test koszyka i płatności – to najdroższe ścieżki na stronie.

Budżet na dostępność: SLO

“Chcemy, żeby strona działała” to nie wymaganie. Wymaganie to liczba. Standard branżowy to 99,9% – i warto policzyć, co to znaczy:

Ustal budżet na dostępność (SLO) wspólnie z klientem i mierz go co miesiąc. Przekroczenie budżetu powinno uruchamiać retrospektywę: co zawiodło, dlaczego, co zmieniamy. Sam raport “99,9% uptime w tym miesiącu” bez kontekstu nic nie mówi – ważne, ile z tego było w godzinach pracy użytkowników.

Raporty i wskaźniki

Właściciel strony nie potrzebuje dashboardu, potrzebuje jednej liczby miesięcznie. Zbuduj raport, który pokazuje:

• Uptime % – z podziałem na planowane i nieplanowane przerwy,
• MTTR (Mean Time To Repair) – ile trwało przywrócenie,
• Liczbę incydentów i ich kategorie (DNS, SSL, serwer, kod),
• Trend wydajności – medianę czasu odpowiedzi i TTFB.

UptimeRobot generuje podstawowe raporty, ale do poważnego wdrożenia dołóż Grafana + Prometheus (blackbox_exporter) albo gotowy stack jak Uptime Kuma (open-source, self-hosted). Dane historyczne są kluczowe: bez nich nie udowodnisz klientowi poprawy, a przy każdej awarii zaczynasz od zera.

Checklist wdrożenia

• Uptime check głównej domeny (interwał ≤ 5 min, kilka lokalizacji)
• Monitor SSL z wyprzedzeniem 30 dni
• Monitor API/endpointów krytycznych
• Alerty z eskalacją (e-mail → SMS/push) i deduplikacją
• Publiczna status page
• Syntetyczny test formularza (i płatności, jeśli sklep)
• Raport miesięczny: uptime, MTTR, incydenty, trend wydajności
• SLO zapisane w umowie/readme, mierzone co miesiąc

Co dalej

• Cloudflare dla WordPressa
• GEO vs SEO: optymalizacja pod AI
• Wyszukiwarki AI a ranking Google

Jeśli chcesz, żebym postawił pełny monitoring (uptime, SSL, syntetyczne testy, status page i miesięczne raporty) pod twoją stronę – napisz do mnie. Konfiguracja zajmuje 1-2 dni, koszt od 600 PLN.