O większości poważnych problemów ze stroną dowiadujemy się za późno – i to nie od monitoringu, tylko od klienta.
Certyfikat SSL wygasa cicho, aż przeglądarka zaczyna straszyć ostrzeżeniem, a ruch spada do zera. Backup nikt nie sprawdza, dopóki nie trzeba go odtworzyć – wtedy jest już za późno, żeby dowiedzieć się, że od tygodni się nie wykonywał. A gdy strona przestaje odpowiadać, zwykle pierwszy dzwoni klient. To najgorsza możliwa forma monitoringu.
Z tego problemu Piotrek, jeden z naszych kursantów, zbudował Latarnika – automat, który ma zauważyć problem, zanim zauważy go klient.
Jak działa Latarnik
Uptime co godzinę
HTTP status, czas odpowiedzi, ważność certyfikatu TLS.
Dzienny audyt UX / SEO / a11y
Playwright + axe-core na realnej przeglądarce, nie tylko ping.
Interpretacja AI
Surowe dane zamieniają się w priorytety i konkretne zalecenia, nie w kolejny raport do przejrzenia.
Wynik trafia na maila – zanim zadzwoni klient, nie zamiast tego.
Rano czeka gotowy raport
Codzienny audyt zostawia po sobie log, który czyta się jak lista rzeczy do zrobienia, nie jak zrzut danych:
latarnik audit --daily
06:00:02 ✓ uptime 200 OK · 412 ms
06:00:09 ! wydajność LCP 4.8 s (wczoraj 1.2 s)
06:00:14 ✕ a11y 3 × kontrast < 4.5:1
06:00:15 ✕ a11y 2 × obraz bez alt
06:00:18 ! seo brak meta description
06:00:21 ! coverage 61 % JS nieużywany
06:00:24 → raport wysłany na mail
Z tego samego przebiegu AI wyciąga wnioski w kolejności ważności, a nie w kolejności wykrycia:
- P1 – kontrast przycisku CTA to 2,4:1, a to jedyna ścieżka konwersji na stronie.
- P2 – LCP wzrósł czterokrotnie po wczorajszym wdrożeniu.
- 4 uwagi z tego przebiegu zostały pominięte w raporcie, bo były już zgłoszone wcześniej.
Ten ostatni punkt jest równie ważny co pierwsze dwa. Latarnik nie zasypuje tym samym błędem codziennie – zgłasza go raz i pamięta, że już to zrobił.
Nie prompt, ale pipeline
Surowy audyt to kilkaset linii JSON-a. Zanim trafi do modelu, LangChain porządkuje go w łańcuch kroków, z których każdy ma jedno zadanie:
| Krok | Zadanie |
|---|---|
loader | Normalizuje wyniki Playwrighta i axe-core do jednego, spójnego schematu zdarzeń |
memory | Trzyma historię zgłoszeń w wektorowym store – raz zgłoszony problem nie wraca |
chain | Claude ocenia wpływ na podstawie promptu z kontekstem strony, nie gołej listy błędów |
parser | Zwraca structured output – typowany obiekt z priorytetem, powodem i zaleceniem |
chain = normalize | recall_known | claude | parse_priorities
Ten podział ma znaczenie: model nie dostaje surowego zrzutu błędów z poleceniem „oceń”. Dostaje już znormalizowane dane i wie, co zostało zgłoszone wcześniej – dzięki czemu jego jedyną robotą zostaje ocena wpływu i priorytetyzacja, a nie odgadywanie kontekstu.
Co wykrywa Latarnik
Sześć obszarów w jednym przebiegu: uptime i czas ładowania, błędy JS w konsoli (wyjątki i failed requesty z realnej sesji), dostępność (kontrast, atrybuty alt, struktura nagłówków), SEO (title, meta description, pojedynczy H1), nieużywany kod (JS/CSS coverage) oraz porady UX z AI – jako priorytety, nie jako kolejna lista.
Stack
Node.js jako runtime, Playwright do symulacji realnej przeglądarki, axe-core do audytu dostępności, Claude API spięte LangChainem do interpretacji, Nodemailer (SMTP) do powiadomień i GitHub Actions jako scheduler – dwa harmonogramy, jeden na uptime co godzinę (0 * * * *), drugi na pełny audyt raz na dobę (0 4 * * *). GitHub Actions liczy czas w UTC, więc audyt o 4:00 UTC ląduje na skrzynce około 6:00 rano czasu polskiego – stąd godziny w przykładowym raporcie wyżej.
To nie kolejny pinger
| Klasyczny monitoring | Latarnik | |
|---|---|---|
| Częstotliwość | ping co 5 minut | uptime co godzinę + audyt co dobę |
| Odpowiedź | żyje / nie żyje | co, gdzie i dlaczego |
| Alert | dopiero przy awarii | z priorytetem i zaleceniem |
| Powtarzalność | codziennie to samo | pamięta, co już zgłosił |
Klasyczny monitoring odpowiada na jedno pytanie: czy strona żyje. Latarnik odpowiada na drugie, trudniejsze: co jest z nią nie tak i od czego zacząć.
„Strażnik »Latarnik« i możesz spać spokojnie”.
Opis i pełna prezentacja projektu są na Instagramie autora.
To kolejny z projektów, jakie kursanci StormIT budują dla siebie w trakcie nauki. Zobacz pozostałe albo sprawdź, jak zacząć swój.