Co dzieje się z aplikacją po starcie — monitoring, aktualizacje, incydenty?

Trzy pętle: co naprawdę dzieje się z aplikacją po starcie?

Start produkcyjny nie jest końcem pracy, tylko zmianą jej rodzaju. Od tego dnia aplikacja żyje w trzech pętlach, które kręcą się niezależnie od siebie: monitoring, aktualizacje i incydenty.

Monitoring odpowiada na pytanie, czy działa i dla kogo. Aktualizacje pilnują, żeby to, co działa dziś, działało też po zmianie przeglądarki, biblioteki albo interfejsu dostawcy. Incydenty to procedura na moment, w którym pierwsze dwie pętle nie wystarczyły.

Różnica między aplikacją utrzymywaną a włączoną jest mierzalna. Utrzymywana ma nazwaną osobę, kanał alertu i okno wykrycia liczone w minutach. Włączona ma adres i nadzieję, że ktoś zadzwoni.

Trzy pętle nie wymagają trzech zespołów ani trzech płatnych narzędzi. Wymagają trzech nazwanych osób do trzech różnych sytuacji i jednego miejsca, w którym widać, co się wydarzyło.

Monitoring: co mierzyć poza „czy strona się otwiera”?

Sprawdzanie adresu głównego to najmniejsza wersja monitoringu i najczęściej jedyna, jaką ktoś włącza. Adres odpowiada poprawnie także wtedy, gdy logowanie jest zepsute, wpłata nie dochodzi, a poczta stoi w kolejce.

Cztery sygnały wystarczą do pierwszych kilkuset kont: dostępność adresu i ekranu logowania, odsetek odpowiedzi 5xx, czas odpowiedzi najwolniejszej ścieżki oraz zdarzenia pieniężne — nieudane powiadomienie operatora płatności i nieudana wysyłka poczty.

Interwał decyduje o tym, ile trwa cisza. W planie darmowym UptimeRobot to 50 monitorów sprawdzanych co 5 minut (odczyt 31 sierpnia 2026), więc awaria bywa niewidoczna przez pięć minut plus czas dojścia alertu.

Better Stack w planie darmowym daje mniej punktów — 10 monitorów i heartbeatów oraz jedną stronę statusu — ale sprawdza nawet co 30 sekund (odczyt 31 sierpnia 2026). Wybór między nimi jest wyborem między liczbą punktów a rozdzielczością czasu.

Śledzenie błędów mieści się w planach darmowych na długo po starcie. Better Stack podaje 100 000 wyjątków miesięcznie, Sentry dla planu darmowego podaje 5 000 błędów — ale okresu rozliczeniowego przy tym planie nie znaleźliśmy w dokumentacji na dzień 31 sierpnia 2026, więc liczymy z planu, który podaje go wprost.

Alert bez adresata nie jest alertem. Stosujemy prostą regułę: nieudane zdarzenie płatnicze i nieudana wysyłka poczty idą na kanał, który ktoś czyta tego samego dnia, a nie do logu, do którego zagląda się dopiero po awarii.

Do tego jedna lekcja z praktyki. Klient logowania potrafi zwrócić błąd 500 z pustym komunikatem, więc logujemy całą odpowiedź serwera, nie sam kod — inaczej awaria w zgłoszeniu wygląda jak „nie wiadomo co”, a diagnoza zaczyna się od zera.

Aktualizacje: dlaczego nowa wersja nie dochodzi do wszystkich?

W aplikacji instalowanej z przeglądarki wdrożenie nie kończy się na serwerze. Nową wersję musi jeszcze przyjąć Service Worker zapisany w przeglądarce użytkownika, a on ma własne reguły.

Dokumentacja web.dev opisuje je krótko. Skrypt uznaje się za zaktualizowany, jeśli jest „byte-different” wobec tego, który przeglądarka już ma. Aktualizację wyzwala wejście na stronę w zasięgu, a przy zdarzeniach funkcyjnych sprawdzenie nie powtarza się, jeśli było w ciągu poprzednich 24 godzin (odczyt 31 sierpnia 2026).

Dalej jest stan oczekiwania. Po udanej instalacji nowa wersja czeka, aż stara przestanie kontrolować otwarte karty — web.dev nazywa ten stan „waiting”. Wywołanie skipWaiting w nowej wersji pozwala pominąć czekanie i aktywować ją od razu.

Tu wchodzi lekcja z naszej praktyki. Aplikacja instalowana z przeglądarki, chroniona restrykcyjną polityką CSP, wymaga jawnego wypisania źródeł skryptów. Bez tego aktualizacja nie dochodzi do części użytkowników, a w logach nie widać żadnej awarii — wszystko odpowiada poprawnie, tylko starym kodem.

Druga warstwa aktualizacji to zależności. Node.js opisuje wsparcie wydania LTS jako gwarancję poprawiania krytycznych błędów przez „a total of 30 months” (odczyt 31 sierpnia 2026). Po tym oknie środowisko pod aplikacją przestaje dostawać poprawki, a aktualizacja przestaje być wyborem.

Trzecia warstwa leży poza zasięgiem zespołu: zmiany po stronie dostawców. Deklarowana dostępność dotyczy zwykle najdroższego planu — Vercel podaje 99,99% dla platformy serwującej treść, Supabase 99,9% czasu w miesiącu kalendarzowym, oba w planie Enterprise (odczyt 31 sierpnia 2026).

Wniosek jest praktyczny. Aplikacja na planach niższych niż Enterprise nie ma deklarowanej dostępności, więc awaria dostawcy jest ryzykiem właściciela — i dlatego monitoring ma umieć pokazać, że to nie aplikacja przestała działać.

Incydenty: reakcja, naprawa, wpis

Incydent ma trzy takty i tylko pierwszy jest pilny. Reakcja to podjęcie działań: potwierdzenie, że sygnał jest prawdziwy, ocena zasięgu i informacja dla właściciela. Naprawa bywa późniejsza, a czasem świadomie odłożona.

Czasy warto mieć zapisane, zanim będą potrzebne. W naszej praktyce jest to 1 dzień roboczy na zgłoszenia krytyczne i 3 dni na pozostałe, przy czym reakcja oznacza podjęcie działań, a nie zakończoną naprawę.

Podział na krytyczne i pozostałe robi się przed awarią, na spokojnie. Krytyczne to zwykle brak logowania, brak zapisu wpłaty, wyciek danych i aplikacja, która nie odpowiada. Reszta — literówki, wolny ekran, drobne błędy w widoku — ma własny, dłuższy zegar.

Trzeci takt bywa pomijany i to on decyduje, czy błąd wróci. Wpis po incydencie mieści się w jednym akapicie: co się stało, od kiedy do kiedy, kogo dotknęło, jaka była przyczyna, co zmieniliśmy i po czym poznamy powtórkę.

Dwie rzeczy sprawdza się poza incydentem, bo w trakcie jest już za późno. Pierwsza: kopie testujemy odtworzeniem, nie istnieniem pliku — zasady i test bez programisty opisaliśmy w tekście o bezpieczeństwie od pierwszego dnia.

Druga to obowiązki wobec organu nadzorczego, gdy incydent dotyczy danych osobowych. Terminy i brzmienie przepisu są w tym samym tekście. Tutaj wystarczy zasada: zegar rusza od stwierdzenia naruszenia, a nie od zakończenia naprawy.

Po czym poznać porządną opiekę po starcie?

Dziewięć pytań, które właściciel aplikacji zada bez wiedzy technicznej. Każde ma odpowiedź w postaci nazwiska, liczby albo daty — a odpowiedź „to zależy” jest w każdym z nich odpowiedzią negatywną.

• Kto dostaje pierwszy sygnał i na jaki kanał? Odpowiedź ma zawierać osobę i miejsce, do którego ta osoba naprawdę zagląda. Skrzynka bez dyżuru nie jest kanałem alertu.
• Co jest sprawdzane i jak często? Lista monitorów i interwał. Sam adres główny co pięć minut to minimum, nie komplet — ekran logowania i ścieżka płatności też są punktami.
• Gdzie trafia nieudane powiadomienie o wpłacie? Ma trafiać do człowieka tego samego dnia. Log, do którego zagląda się po awarii, nie liczy się jako miejsce.
• Jaki jest zapisany czas reakcji i co ten czas oznacza? Reakcja to podjęcie działań, nie naprawa. Bez tego rozróżnienia obie strony czytają ten sam zapis inaczej.
• Kiedy było ostatnie wdrożenie i kiedy aktualizowano zależności? Dwie daty. Aplikacja bez wdrożenia od wielu miesięcy nie jest stabilna, tylko nieruszana.
• Kiedy odtworzono kopię i ile to trwało? Data i czas. Odpowiedź, że kopie się robią, mówi o pliku, nie o odtworzeniu.
• Czy po ostatnim incydencie powstał wpis? Jeden akapit do przeczytania. Brak wpisu oznacza, że przyczyny nikt nie nazwał, więc może wrócić.
• Na kogo są konta u dostawców? Hosting, baza, operator płatności, poczta i domena mają stać na firmie właściciela. Zespół utrzymania dostaje dostęp, nie własność.
• Co się dzieje, gdy awarię ma dostawca? Odpowiedź ma wskazać, skąd zespół to wie i co w takim razie widzi użytkownik. W dokumentach SLA obu dostawców zobowiązanie jest przypisane do planu Enterprise (u Vercela wynika to z tytułu dokumentu, nie z osobnej klauzuli); dla niższych planów deklaracji nie znaleźliśmy na dzień 31 sierpnia 2026.

Jeśli na trzy z tych pytań pada odpowiedź „sprawdzimy”, opieki nie ma — jest gotowość do reagowania na telefon od klienta. To działa do pierwszej awarii w piątek wieczorem.

Czego ten tekst nie rozstrzyga?

Nie ma tu rachunku utrzymania w złotych ani porównania planów płatnych. Ten rachunek prowadzimy osobno, w tekście o koszcie aplikacji w trzy lata.

Nie ma też zasad odbioru ani gwarancji na to, co zostało odebrane. Kolejność prac, artefakty i akceptacje opisuje tekst o budowie aplikacji krok po kroku, a warstwy, które trzeba obserwować — tekst o warstwach aplikacji dla firmy.

Ten artykuł opisuje jedno: co dzieje się z aplikacją między jednym wdrożeniem a drugim, kto to widzi i w jakim czasie. Reszta decyzji ma swoje miejsce i swoje liczby.