Automatyczne alerty uptime, Core Web Vitals i SSL to infrastruktura monitoringu, która chroni stronę przed niewidocznymi problemami – downtime w nocy, gasnąca wydajność po deployu, wygasający certyfikat SSL. Każde z tych zdarzeń może kosztować 20–60% ruchu organicznego w kilka dni, zanim zauważysz ręcznie. Setup automatycznych alertów to 2–4 godziny, zysk – tygodnie zaoszczędzonej diagnostyki.
Ten przewodnik to konkretny setup trzech warstw monitoringu infrastrukturalnego: uptime, Core Web Vitals, SSL. Narzędzia, progi, kanały komunikacji – wszystko w 300 zł/miesiąc budżetu, z opcjami enterprise dla większych projektów.
W skrócie
- Trzy warstwy monitoringu: uptime (strona działa), Core Web Vitals (strona jest szybka), SSL (certyfikat nie wygasa).
- Narzędzia: UptimeRobot, Pingdom, Sematext, SpeedCurve, SSL Labs API, CheckCertExpiry.
- Budżetowy stack: 0–100 zł/miesiąc pokrywa wszystko dla pojedynczej strony.
- Enterprise: 300–1500 zł/miesiąc dla multi-site agencji z SLA.
- Kanały: Slack/Discord (natychmiastowe), email (dzienne), SMS (krytyczne).
Uptime monitoring – strona musi działać
Strona niedziałająca nie jest indexowana, nie rankuje, nie konwertuje. Każde 5 minut downtime to realny koszt biznesowy. Monitoring uptime jest obowiązkowy – nie „opcjonalny ładny dodatek”. Szerzej omawiamy to w monitoring pozycji SERP.
Co monitorować
- Homepage – podstawowy check, 1-minutowy interval.
- Strony produktowe / category pages – top 20 po ruchu.
- Checkout / formularze kontaktowe – konwersja zależy.
- API endpoints – jeśli frontend używa, check zdrowia API.
- Login/authentication – użytkownicy muszą się logować.
Progi alertu
- Downtime > 1 minuta – alert do Slack.
- Downtime > 5 minut – alert SMS do on-call engineer.
- Downtime > 15 minut – eskalacja do CTO.
- Status code anomalie (np. 500 w 10%+ checków) – alert.
Narzędzia uptime
| Narzędzie | Free plan | Paid plan | Najlepsze do |
|---|---|---|---|
| UptimeRobot | 50 monitorów, 5-min interval | $7/mies Premium | Budżet, freelancerzy |
| Pingdom | – | $10–70/mies | SMB z dokładnym reportingiem |
| Sematext Synthetics | 2 monitory free | $25+/mies | Advanced UI testing |
| BetterStack (Better Uptime) | 10 monitorów free | $18+/mies | Nowoczesny UI, status pages |
| Datadog Synthetics | – | $5 per 10k checks | Enterprise z observability |
| StatusCake | 10 monitorów free | $20+/mies | UK-based, dobra geografia |
Setup UptimeRobot za darmo
- Konto UptimeRobot – 5 minut.
- Dodaj monitor HTTP(S): URL strony, interval 5 min.
- Powtórz dla 10–15 kluczowych URL-ów (free plan daje 50).
- Skonfiguruj alerty: email, Slack webhook, Discord.
- Gotowe – pełen uptime monitoring za 0 zł.
Core Web Vitals monitoring
Core Web Vitals to LCP, INP, CLS – metryki Google, które wpływają na rankingi (mały, ale realny sygnał) i konwersję (znaczącą). Monitoring w czasie rzeczywistym wykrywa regresję po deployu. Powiązane zagadnienia opisujemy w narzędzia SEO.
Co monitorować
- LCP (Largest Contentful Paint) – target < 2,5 s na 75 percentylu.
- INP (Interaction to Next Paint) – target < 200 ms na 75 percentylu.
- CLS (Cumulative Layout Shift) – target < 0,1.
- TTFB (Time to First Byte) – serwer, target < 600 ms.
Field data vs lab data
- Field data (CrUX) – prawdziwi użytkownicy, dane z 28 dni. Rolling window. To są dane, których używa Google do rankingu.
- Lab data (Lighthouse) – syntetyczny test w kontrolowanym środowisku. Dobry do regression testing, ale nie odzwierciedla prawdziwego UX.
- RUM (Real User Monitoring) – twoje własne pomiary przez web-vitals.js JavaScript library. Najdokładniejsze.
Narzędzia CWV monitoring
| Narzędzie | Typ danych | Cena |
|---|---|---|
| Google PageSpeed Insights API | Lab + field | free |
| Google Search Console | Field (CrUX) | free |
| web-vitals.js + custom dashboard | RUM | free (serwer opłacalny) |
| SpeedCurve | Lab + RUM | $19+/mies |
| Calibre | Lab, regression | $99+/mies |
| DebugBear | Lab + RUM, budget | $10+/mies |
| New Relic Browser | Enterprise RUM | $99+/mies |
Setup budżetowy: PageSpeed Insights API + Slack
- Node.js skrypt pobierający PSI API co 6 godzin dla top 20 URL.
- Zapis w Google Sheet lub BigQuery.
- Alert jeśli LCP > 3s, INP > 300ms, CLS > 0,15.
- Webhook do Slack – „regression detected na URL X, LCP było 2,1s, teraz 3,4s”.
- Cron: 4 razy dziennie, 80 requestów – w limits darmowego planu PSI API.
Setup RUM: web-vitals.js
- Dodaj
<script src="https://unpkg.com/web-vitals/dist/web-vitals.iife.js"></script>do <head>. - JavaScript wysyła eventy LCP/INP/CLS do GA4 lub własnego endpoint.
- GA4 Reports → Custom report dla CWV distribution.
- Alert w GA4: nagły spadek 75 percentyla LCP.
- Koszt: 0 zł (GA4 free, unlimited events w ramach limitów).
SSL certificate monitoring
Wygasły certyfikat SSL to katastrofa – użytkownicy widzą „not secure”, CTR spada o 70–90%, rankingi spadają, Google indexing siada. SSL monitoring to 5-minutowy setup, który zapobiega dniom kryzysu. Praktyczne wskazówki zawiera przewodniku po stacku marketingowym 2026.
Co monitorować
- Data wygaśnięcia – alert 30, 14, 7, 3 dni przed.
- Poprawność łańcucha certyfikatów – incomplete chain powoduje błędy w niektórych przeglądarkach.
- Protokół TLS – minimum TLS 1.2, idealnie TLS 1.3. TLS 1.0/1.1 deprecated.
- Cipher suites – bez weak ciphers (RC4, DES).
- HSTS header – obecny i działający.
Narzędzia SSL monitoring
- SSL Labs Test – free online tool, scoring A-F. Raz miesięcznie manual check top domen.
- UptimeRobot SSL monitoring – free, alert 30 dni przed wygaśnięciem.
- KeyCDN SSL checker – free API, automatyzacja.
- Cloudflare – automatyczne SSL management, alert przy problemach.
- Let’s Encrypt + certbot – automatyczne odnowienia co 90 dni.
Setup automatycznych odnowień
- Jeśli hosting – sprawdź auto-renew (WP Engine, Kinsta, Shopify mają auto).
- Jeśli self-hosted – certbot z cronem co 60 dni (auto-renew dla Let’s Encrypt).
- Jeśli commercial CA (GeoTrust, DigiCert) – kalendarz remindersem 60 dni przed.
- Backup monitor – UptimeRobot z SSL check jako safety net.
Kanały komunikacji alertów
| Poziom | Sytuacja | Kanał | Target response time |
|---|---|---|---|
| P0 krytyczny | Downtime > 5 min, SSL expired | SMS + Slack + email | 5 minut |
| P1 wysoki | Downtime 1–5 min, CWV regression > 50% | Slack + email | 30 minut |
| P2 średni | SSL za 30 dni, CWV drop 20–50% | 24 godziny | |
| P3 info | Tygodniowe reporty trendów | Email digest | tygodniowo |
On-call rotation
Dla zespołów > 3 osób – rotacja on-call tygodniowa lub miesięczna. PagerDuty, Opsgenie, BetterStack integrują się z alertami. Dla małych zespołów – jeden dedykowany ownere monitorowania + bezpiecznie second dla urlopu.
Case: alerty uratowały Black Friday
E-commerce fashion, rok 2024, Black Friday peak. Alert UptimeRobot o 00:23 – homepage zwraca 500. Owner on-call zobaczył notyfikację o 00:25, połączył z DevOps o 00:30. Przyczyna: memory leak w cache plugin po deploymencie tego samego dnia.
Timeline incydentu
- 00:23 – UptimeRobot wykrywa 500 error.
- 00:25 – Slack alert + SMS do on-call.
- 00:30 – DevOps połączony, restart serwera.
- 00:35 – site up, investigation.
- 00:50 – disable cache plugin, full recovery.
- 01:00 – permanentny fix deployed.
Impact
- Downtime total: 27 minut.
- Zgubione konwersje: ~45 tys. zł (wg post-mortem).
- Bez alertu: prawdopodobnie 6–8 godzin downtime do rana (oszacowana strata 400–600 tys. zł na peak Black Friday).
- Koszt alertów: 0 zł/mies (UptimeRobot free tier).
- ROI setup: 40 tys. zł saved / 30 min setup = ~800 tys. zł/godzina ROI.
Najczęstsze błędy
Błąd 1: Monitoring tylko homepage
Homepage może działać, a checkout/produkt nie. Monitoruj 10–20 kluczowych URL, nie tylko główną.
Błąd 2: Za wolny interval
Check co 15 minut = możliwy 15-min downtime niewykryty. Minimum 1–5 minut dla krytycznych stron.
Błąd 3: Alerty bez on-call
Alert o 3:00 w nocy, nikt nie widzi – bez on-call rotation to tylko pseudobezpieczeństwo. Zdefiniuj kto reaguje i o której.
Błąd 4: Ignorowanie false positive
Alert z zagranicznego IP – może być chwilowy routing issue. Wymagaj 2+ consecutive failures z różnych lokacji przed alertem P0.
Błąd 5: Brak post-mortem po incydencie
Każdy incydent to okazja do nauki. 15-minut post-mortem: co się stało, kiedy wykryte, jak naprawione, jak zapobiec powtórzeniu. Dokumentuj.
FAQ — najczęstsze pytania
Czy UptimeRobot free jest wystarczający dla małej strony?
Tak, dla 1 strony z 10–20 kluczowymi URL-ami free plan wystarczy. 50 monitorów, 5-min interval, email/Slack alerts. Ograniczenia: brak SMS, brak integracji PagerDuty, mniej szczegółowy reporting. Jeśli chcesz SMS – upgrade do Premium ($7/mies) albo dodatkowy darmowy tool obok (BetterStack free).
Jaką częstotliwość checków ustawić?
Krytyczne strony (homepage, checkout): 1 minuta. Ważne (kategorie, top produkty): 5 minut. Pozostałe: 15 minut. Zbyt częste checks z darmowych narzędzi mogą wywołać rate limit lub IP ban. Zbyt rzadkie – nie wykryjesz krótkich incydentów. Optimum: 1–5 minut dla top 20 URL, 15 min dla reszty.
Czy Core Web Vitals w GSC wystarczą?
Dla ogólnego obrazu tak, dla szybkiej reakcji nie. GSC CWV data ma 28-dniowe rolling window i update co kilka dni – nie wykryjesz regresji w 24h. Do real-time CWV: własny RUM (web-vitals.js + GA4), DebugBear, SpeedCurve. GSC używaj jako baseline i Google-approved źródło truth.
Jak monitorować SSL chain na wielu domenach?
Dla 1–5 domen – UptimeRobot SSL monitoring free. Dla 10–50 domen – skrypt Python/Node z OpenSSL cert check, cron co tydzień, alert przy < 30 dni to expiry. Dla enterprise (100+) – SSL monitoring dashboard w New Relic, Datadog, SolarWinds, lub self-hosted pipeline z Prometheus + Alertmanager.
Czy alerty mogą generować false positives?
Tak, często. Główne źródła: chwilowe problemy routing (3–30 sek), deploy-time blips, maintenance windows. Rozwiązania: wymagać 2+ consecutive failures, filtrować znane maintenance, multi-region checks (failure z 1 regionu = nie alert, failure z 3/5 = alert). Dobrze skonfigurowany monitoring ma < 5% false positive rate.
Co zrobić po incydencie downtime?
Post-mortem w 24h: root cause analysis, timeline, impact assessment, prevention plan. Dokumentuj w Notion/Confluence. Status page update dla użytkowników. Jeśli impact > 1h downtime, publiczny blog post o transparencji. Ważne – nie winić pojedynczych osób, skupiać się na procesie i narzędziach, które pozwoliły problemowi przejść nie wykryty.
Co dalej
Na początek sprawdź monitoring pozycji SERP. Gdy opanujesz podstawy, przejdź do alerty SERP — tam czekają zaawansowane techniki.