Najdroższa awaria, jaką u siebie zaliczyłem, nie wyglądała jak awaria. Formularz na stronie działał, workflow się odpalał, użytkownik widział ekran podziękowania. Tylko zgłoszenia nie dochodziły do CRM, bo integracja odpowiadała błędem autoryzacji, a workflow kończył się porażką i nic więcej się nie działo. Przez kilka dni żyłem w przekonaniu, że po prostu mamy słabszy tydzień.
To jest domyślny tryb awarii automatyzacji: nie huk, tylko cisza. Serwer stoi, panel świeci na zielono, nikt nie dzwoni. Dlatego pytanie „ile automatyzacji nam zbudujecie" jest mniej ważne od pytania „skąd się dowiemy, że przestały działać". Drugie słyszę rzadko i prawie zawsze od kogoś, kto już to raz przeżył.
Poniżej opisuję system, którym pilnujemy automatyzacji u siebie i u klientów: sześć warstw, z których każda łapie inny rodzaj awarii, plus część organizacyjna, bez której najlepszy alert ląduje w pustym kanale. Piszę też, kiedy to wszystko jest przerostem formy nad treścią, bo firma z trzema prostymi automatyzacjami nie potrzebuje centrum monitorowania.
TL;DR: Monitoring automatyzacji ma sześć warstw: alert o błędzie z narzędzia (error workflow), alarm o tym, że coś się nie wykonało (dead man's switch), healthcheck usług z sondą sprawdzającą realną gotowość, metryki wolumenu (spadek liczby leadów przy braku błędów), okresowa rekoncyliacja liczb między systemami i przypisany człowiek z runbookiem. Pierwsza i druga warstwa łapią większość awarii i zajmują popołudnie. Reszta jest dla procesów dotykających pieniędzy.
Cisza nie znaczy, że działa
W większości firm monitoring automatyzacji istnieje w jednej postaci: ktoś zauważy, że coś nie gra. Handlowiec zapyta, dlaczego od wtorku nie ma zgłoszeń. Księgowa zorientuje się, że faktury z zeszłego tygodnia nie wyszły. Klient napisze, że nie dostał potwierdzenia zamówienia. Odstęp między awarią a odkryciem liczy się wtedy w dniach, a przy procesach z niskim wolumenem w tygodniach.
Dzieje się tak, bo brak sygnału odbieramy jako sygnał, że jest dobrze. Kiedy proces zostaje zautomatyzowany, przestajesz go dotykać, a razem z tym tracisz mimowolną kontrolę, którą dawało ręczne wykonywanie. Nikt nie przepisuje już leadów do CRM, więc nikt nie zauważy, że przez trzy dni nie było czego przepisywać.
„Awaria, która rzuca czerwonym błędem, jest tania, bo widać ją tego samego dnia. Drogie są te, po których wszystko dalej wygląda normalnie: proces się odpala, kończy sukcesem i po prostu nie robi tego, co miał robić. W firmach, które audytujemy, takie awarie zwykle trwają od tygodni." — Mikołaj Brunka, założyciel NoCodeWork
I tu robi się nieprzyjemnie. Sprawdzenie, czy narzędzie działa, jest proste i zajmuje minutę. Sprawdzenie, czy dzieje się to, co ma się dziać, wymaga zupełnie innych mechanizmów, i to o nich jest reszta tego tekstu. Sygnały ostrzegawcze, które widać jeszcze przed pierwszą cichą awarią, zebraliśmy osobno w tekście o pięciu oznakach źle wdrożonej automatyzacji.
Sześć warstw monitoringu
Każda z warstw łapie inny rodzaj awarii i żadna nie zastępuje pozostałych. Nie wdrażaj ich naraz. Kolejność w tabeli to jednocześnie kolejność wdrażania.
| # | Warstwa | Co wykrywa | Czego nie wykryje |
|---|---|---|---|
| 1 | Error workflow w narzędziu | Wykonanie zakończone błędem | Procesu, który się nie uruchomił |
| 2 | Dead man's switch | Brak wykonania w oknie czasowym | Wykonania, które przeszło z pustym wynikiem |
| 3 | Healthcheck usługi | Aplikacja nie odpowiada lub nie jest gotowa | Błędu logiki wewnątrz działającej aplikacji |
| 4 | Metryki wolumenu | Nagły spadek liczby leadów, zamówień, wysyłek | Danych zapisanych w złe miejsce |
| 5 | Rekoncyliacja okresowa | Rozjazd liczb między systemami | Awarii trwającej krócej niż okres kontroli |
| 6 | Właściciel i runbook | Alert, na który nikt nie zareagował | Niczego technicznie, i o to chodzi |
Pierwsze dwie warstwy dają najwięcej za najmniej pracy. Jeśli masz zrobić tylko jedną rzecz po przeczytaniu tego tekstu, zrób warstwę pierwszą.
Warstwa 1: alert o błędzie z narzędzia
Każda platforma automatyzacji wie, kiedy wykonanie skończyło się porażką. Problem w tym, że domyślnie zapisuje to do własnego logu i czeka, aż ktoś tam zajrzy. W n8n mechanizmem, który wyciąga to na zewnątrz, jest error workflow: osobny przepływ z węzłem Error Trigger, wskazany w ustawieniach pozostałych workflow. Dostaje nazwę workflow, krok, na którym się wywróciło, treść błędu i link do konkretnego wykonania.
Dobry alert mieści się na ekranie telefonu i odpowiada na trzy pytania: co padło, czego dotyczyło i gdzie kliknąć, żeby to naprawić. „Błąd w workflow" nie odpowiada na żadne. Techniczną stronę wysyłki, konfigurację Error Triggera i pułapki przy Slacku oraz Teams rozpisaliśmy w artykule o powiadomieniach z n8n na Slacka i Teams.
Dwie rzeczy, o których łatwo zapomnieć. Error workflow reaguje wyłącznie na wykonania produkcyjne, więc testu nie zrobisz kliknięciem „uruchom" w edytorze, tylko prawdziwym przebiegiem z celowo zepsutym krokiem. I dołóż od razu deduplikację, bo jeden zepsuty webhook potrafi wygenerować dwieście alertów w kwadrans: pierwszy wysyłaj natychmiast, kolejne zliczaj i podsumuj po godzinie.
Osobno sprawa pieniędzy. Tam, gdzie po drodze można zgubić zgłoszenie od klienta, sam alert o błędzie nie wystarczy. Ścieżka awaryjna powinna wysłać treść tego zgłoszenia, żeby dało się je obsłużyć ręcznie, zanim ktokolwiek naprawi integrację. Doszliśmy do tego po opisanym wyżej tygodniu bez leadów. Więcej o naszym własnym stosie, razem z wpadkami, opisałem w tekście o tym, co sami u siebie uruchomiliśmy.
Warstwa 2: alarm, gdy coś się nie wykonało
Warstwa pierwsza ma jedną dziurę i jest ona duża: nie zgłosi procesu, który w ogóle nie wystartował. Wyłączony harmonogram, wygasły token przy triggerze, zapauzowany workflow, wyczerpany limit wykonań w planie, przemianowany webhook. We wszystkich tych przypadkach nie ma błędu, bo nie ma czego zepsuć. Jest cisza.
Odwrotność zwykłego monitoringu nazywa się dead man's switch, czyli czuwak. Zamiast czekać na sygnał o awarii, czekasz na sygnał, że wszystko poszło dobrze, i alarmujesz wtedy, gdy on nie przyjdzie na czas. Mechanika jest prosta: na końcu udanego wykonania workflow wysyła krótkie żądanie pod adres monitorujący. System monitoringu ma zapisane, jak często ten sygnał ma przychodzić, i jeśli minie okno tolerancji, wysyła alert.
Czuwakiem obejmij wszystko, co ma harmonogram i konsekwencje: nocną synchronizację stanów magazynowych, poranny raport sprzedażowy, cotygodniowe zestawienie faktur, comiesięczne rozliczenie godzin. Okno tolerancji ustaw na normalny interwał plus zapas na wolniejsze wykonanie, żeby zadanie z 3:00 w nocy nie budziło nikogo alarmem o 3:05.
Warstwa 3: healthcheck, który naprawdę sprawdza
Trzecia warstwa dotyczy usług pod automatyzacjami: instancji n8n, bazy danych, aplikacji wewnętrznej, API, z którym rozmawiają workflow. Standardowo monitoring odpytuje ich adres co minutę i sprawdza, czy dostał odpowiedź.
Tu jest pułapka, którą sami sobie zastawiliśmy. Sonda pukająca w stronę główną aplikacji uznaje każdą odpowiedź za dowód życia, a aplikacja potrafi zwrócić ładny ekran błędu z kodem sukcesu. Formalnie odpowiada, faktycznie jest martwa: straciła połączenie z bazą albo wisi na pełnej kolejce. Monitoring świeci na zielono przez cały czas trwania awarii.
Naprawa polega na tym, żeby aplikacja miała osobny adres do sprawdzania gotowości, zwracający sukces tylko wtedy, gdy naprawdę może pracować, czyli ma połączenie z bazą i wczytaną konfigurację. Sonda pyta wtedy o gotowość, a nie o to, czy serwer w ogóle odpowiada.
Drugi element tej warstwy to automatyczna reakcja: gdy kontener przestaje przechodzić healthcheck, proces nadzorujący sam go podnosi. Większość awarii aplikacyjnych to zawieszenie, które restart naprawia w kilkanaście sekund. Warunek jest jeden. Automatyczny restart nie może być cichy, bo restart, o którym nikt się nie dowiaduje, zamienia poważny problem powtarzający się co godzinę w drobny szum w tle.
Warstwy 4 i 5: wolumen i rekoncyliacja
Zostaje najbardziej podstępna klasa awarii: wszystko technicznie działa, a proces nie robi swojego. Zmienia się nazwa pola w formularzu i rekordy w CRM lądują puste. Reguła filtrująca odrzuca dziewięć na dziesięć zgłoszeń, bo ktoś poprawił jeden warunek. Żaden alert o błędzie tego nie złapie, bo błędu nie ma.
Łapią to liczby. Metryka wolumenu to alarm o nietypowej liczbie zdarzeń w oknie czasowym: mniej leadów z formularza niż zwykle w dzień roboczy, zero zamówień od trzech godzin w środku dnia, dwa razy więcej wykonań niż zwykle (co zwykle oznacza pętlę). Próg ustaw ręcznie na podstawie danych z ostatnich tygodni i uwzględnij rytm tygodnia. Alarm „brak leadów od 24 godzin" wysłany w niedzielę rano nauczy zespół ignorować ten kanał w dwa weekendy.
Rekoncyliacja okresowa to ta sama myśl w wersji porównawczej: raz na jakiś czas liczysz to samo w dwóch miejscach i sprawdzasz, czy się zgadza. Ile zgłoszeń wysłał formularz, a ile rekordów powstało w CRM. Ile faktur wystawiono, a ile trafiło do księgowości. Ile maili poszło, a ile zostało dostarczonych. Rozjazd nie musi oznaczać awarii, bo część różnic ma normalne wyjaśnienie w duplikatach czy odrzuconych zgłoszeniach. Ale rozjazd, którego nikt nie umie wytłumaczyć, jest najlepszym wskaźnikiem, że proces gubi dane.
Technicznie to jeden workflow z harmonogramem tygodniowym, który zadaje dwa zapytania i wysyła wiadomość z dwiema liczbami. Jeśli masz już raport cykliczny, dołóż ją tam. Jak takie raporty składamy, opisaliśmy przy automatycznych raportach dla zarządu.
Serwer pod automatyzacjami też trzeba pilnować
Jeśli trzymasz n8n na własnym serwerze, dochodzi warstwa infrastruktury. Zebrałem tu cztery rzeczy, za które sami zapłaciliśmy przestojami.
Limity zasobów dla każdej aplikacji. Kontener bez ustawionego limitu pamięci potrafi w godzinę zjeść cały serwer i położyć wszystko, co stoi obok, łącznie z automatyzacjami, które nie miały z nim nic wspólnego. Wygląda to na awarię serwera, a jest awarią jednej aplikacji, której nikt nie ograniczył. Limit ustawia się jedną linijką w konfiguracji i to najtańsza polisa w całym tym tekście.
Watchdog na osobnym serwerze. Monitoring stojący na tej samej maszynie co monitorowane usługi ma jedną wadę: gdy maszyna leży, leży razem z nią i nie wysyła nic. Cisza znów wygląda jak spokój. Przynajmniej jeden obserwator musi mieszkać gdzie indziej, choćby na najtańszym serwerze u innego dostawcy.
Backupy z testem odtworzenia. Kopia, której nikt nigdy nie odtworzył, jest nadzieją, a nie backupem. Do tego jedna pułapka techniczna: bazy SQLite kopiowane w trakcie pracy zwykłym poleceniem kopiowania bywają niespójne, bo część danych siedzi jeszcze w dzienniku zapisu. Na gorąco kopiuje się je wbudowanym mechanizmem bazy. Co dokładnie backupować w n8n, razem z pułapką klucza szyfrowania, opisaliśmy w tekście o backupach i aktualizacjach n8n.
Świadome aktualizacje. Automatyczny aktualizator kontenerów potrafi zrestartować instancję w środku dnia, w trakcie wykonywania workflow. Wyłącz auto-update i aktualizuj w wybranym oknie. Resztę ustawień serwerowych opisaliśmy w przewodniku o stawianiu n8n na własnym serwerze.
Warstwa 6: kto właściwie reaguje
Warstwa najtańsza technicznie i ta, przez którą pozostałe najczęściej okazują się bezużyteczne. Alert bez adresata to log z dodatkowym dźwiękiem. Potrzebne są trzy rzeczy.
Właściciel per automatyzacja, z imienia. Nie „IT" i nie „dostawca". Jedna osoba, która wie, że gdy przyjdzie ten alert, to jest jej alert. Odpowiedzialność rozproszona na trzy osoby oznacza w praktyce zero osób, co widać dopiero przy pierwszej awarii w piątek po południu.
Runbook, czyli co zrobić, gdy. Kilka zdań przy każdej ważnej automatyzacji: co ten proces robi, po czym poznać, że nie działa, co sprawdzić najpierw i co zrobić awaryjnie, żeby firma pracowała dalej. Ostatni punkt jest najważniejszy i najczęściej pomijany. „Do czasu naprawy zgłoszenia obsługujemy ze skrzynki, adres X" pozwala przeżyć dzień bez automatyzacji zamiast czekać z założonymi rękami.
Eskalacja z zegarem. Jeśli właściciel nie potwierdzi alertu w ustalonym czasie, informacja idzie dalej. Bez tego każdy alert wysłany podczas urlopu jest alertem wysłanym w próżnię.
Sprowadza się to do jednej tabeli, którą warto założyć przy trzeciej automatyzacji w firmie: nazwa procesu, właściciel, co się dzieje, gdy nie zadziała, jak długo firma to wytrzyma i gdzie leży runbook. Dwie ostatnie kolumny mówią, którą automatyzację obudować monitoringiem najpierw. Ta sama tabela odpowiada przy okazji na pytanie, czego w ogóle nie warto automatyzować: jeśli w kolumnie „co się dzieje, gdy nie zadziała" wpisujesz „nic", proces nie potrzebuje ani monitoringu, ani automatyzacji.
Czym to zmierzyć: narzędzia
| Narzędzie | Warstwy | Model | Uwagi |
|---|---|---|---|
| Error workflow w n8n | 1 | wbudowane | Zero dodatkowych kosztów, konfiguracja na kilkanaście minut |
| Uptime Kuma | 2, 3 | open source, własny serwer | Monitor typu push obsługuje czuwak; sam wymaga hostingu |
| Healthchecks.io | 2 | SaaS, plan darmowy do 20 zadań, płatny od 20 USD/mies. | Zbudowany wprost pod czuwak (ceny z sierpnia 2026) |
| Workflow z harmonogramem | 4, 5 | to, co już masz | Zapytanie o liczby plus jedna wiadomość na czat |
| Tabela z rejestrem automatyzacji | 6 | arkusz albo baza | Nie wymaga narzędzia, wymaga decyzji |
Wybór między własnym Uptime Kumą a usługą zewnętrzną sprowadza się do jednego pytania: czy monitoring ma przeżyć awarię Twojego serwera. Jeśli tak, nie może na nim stać. My trzymamy Uptime Kumę na drugiej maszynie, a jej samej pilnuje zewnętrzna sonda. Koszt całej tej warstwy to kilkadziesiąt złotych miesięcznie za mały serwer, czyli drobiazg przy pełnym rachunku za utrzymanie instancji.
Jeżeli nie masz w firmie nikogo, kto to poskłada i będzie na to reagować, taniej wychodzi oddanie utrzymania na zewnątrz. Robimy to przy instancjach klientów i mówimy wprost: to najnudniejsza część naszej pracy i jednocześnie ta, która decyduje, czy pozostałe wdrożenia przeżyją drugi rok.
Kiedy monitoring jest przesadą
Sześć warstw dla firmy z trzema automatyzacjami to koszt bez pokrycia. Jeśli Twoje automatyzacje dzieją się w całości wewnątrz jednego narzędzia, nie dotykają pieniędzy i nikt na zewnątrz nie czeka na ich wynik, wystarczy warstwa pierwsza: alert o błędzie na maila i rzut oka na listę nieudanych wykonań raz w miesiącu.
Granicę wyznaczamy trzema pytaniami. Czy przez awarię firma traci pieniądze? Czy dowie się o niej ktoś z zewnątrz, zanim dowiecie się wy? Czy proces ma niski wolumen, przez co brak zdarzeń wygląda normalnie? Jedno „tak" oznacza warstwy 1 i 2, dwa oznaczają dołożenie metryki wolumenu i przypisanie właściciela.
Monitoring nie naprawi też procesu, którego nikt nie opisał. Jeśli nie wiadomo, ile zgłoszeń dziennie jest normą i kto odpowiada za ich obsługę, żaden alert tego nie ustali. Wtedy pierwszym krokiem jest mapa procesu, a nie kolejne narzędzie.
FAQ
Jak dowiedzieć się, że automatyzacja przestała działać?
Potrzebujesz dwóch niezależnych mechanizmów. Pierwszy to alert o błędzie z samego narzędzia, w n8n realizowany przez error workflow z węzłem Error Trigger, który wysyła nazwę workflow, krok i link do wykonania. Drugi to alarm o braku wykonania, czyli dead man's switch: workflow po udanym przebiegu wysyła sygnał do systemu monitoringu, a ten alarmuje, gdy sygnał nie przyjdzie w oknie czasowym. Sam alert o błędzie nie wystarcza, bo nie zgłosi procesu, który w ogóle nie wystartował.
Co to jest dead man's switch w monitoringu automatyzacji?
To monitoring działający odwrotnie niż zwykły: zamiast czekać na sygnał o awarii, oczekuje regularnego potwierdzenia, że wszystko poszło dobrze, i alarmuje przy jego braku. Wdraża się go tak, że na końcu udanego wykonania workflow wysyła krótkie żądanie pod adres monitorujący, a system ma zapisany oczekiwany interwał i tolerancję. Obsługują to między innymi Healthchecks.io i monitor typu push w Uptime Kumie. To jedyna warstwa wykrywająca wyłączony harmonogram, zapauzowany workflow albo wyczerpany limit wykonań.
Dlaczego monitoring pokazuje, że wszystko działa, a proces stoi?
Najczęściej dlatego, że sonda sprawdza niewłaściwą rzecz. Odpytywanie strony głównej aplikacji uznaje za sukces każdą odpowiedź, także ekran błędu zwrócony z kodem sukcesu. Sonda powinna pytać o osobny adres potwierdzający gotowość, który zwraca sukces tylko wtedy, gdy aplikacja ma połączenie z bazą i wczytała konfigurację. Druga częsta przyczyna to monitoring stojący na tej samej maszynie co monitorowane usługi: gdy maszyna leży, nie wysyła nic.
Ile kosztuje monitoring automatyzacji w małej firmie?
Warstwa pierwsza jest darmowa, bo error workflow to funkcja narzędzia. Czuwak w usłudze zewnętrznej mieści się w planie darmowym do kilkunastu zadań, a płatne zaczynają się od około 20 USD miesięcznie (ceny z sierpnia 2026). Własny Uptime Kuma to koszt małego serwera, zwykle kilkadziesiąt złotych miesięcznie. Prawdziwy koszt to czas, a nie licencje: konfiguracja dwóch pierwszych warstw zajmuje kilka godzin, obsługa alertów i przeglądy około dwóch godzin miesięcznie.
Kto powinien odpowiadać za automatyzacje w firmie?
Jedna osoba z imienia przy każdej ważnej automatyzacji, nie dział i nie dostawca. Do tego krótki runbook: co proces robi, po czym poznać awarię, co sprawdzić najpierw i jak obsłużyć sprawę ręcznie do czasu naprawy. Trzeci element to eskalacja z zegarem, czyli przekazanie alertu dalej, gdy właściciel go nie potwierdzi. Firmy bez tej warstwy mają alerty, na które nikt nie reaguje, i dowiadują się o awariach od klientów.
Podsumowanie
Automatyzacja psuje się cicho i to jest cała trudność. Wszystkie sześć warstw służy jednemu celowi: zamienić ciszę w sygnał, zanim zamieni się w telefon od klienta. Error workflow łapie to, co rzuciło błędem, czuwak to, co w ogóle się nie odbyło, a sonda gotowości usługę, która tylko udaje żywą. Metryki wolumenu i rekoncyliacja pilnują najgorszej kategorii, czyli procesów, które kończą się sukcesem i nie robią swojego. Ostatnia warstwa nie jest techniczna: bez przypisanego człowieka z runbookiem żadna z tych wiadomości nie ma znaczenia.
Kolejność ma tu większe znaczenie niż komplet. Zacznij od alertu o błędzie i czuwaka na jednym procesie, tym, który dotyka pieniędzy. To popołudnie pracy i dwie warstwy, które łapią zdecydowaną większość awarii, jakie widzimy u klientów. Resztę dokładaj wtedy, gdy przybywa automatyzacji, a nie z góry, bo monitoring, którego nikt nie ogląda, starzeje się tak samo szybko jak automatyzacja, której nikt nie pilnuje.
Chcesz sprawdzić, które z Waszych automatyzacji przetrwałyby tydzień awarii niezauważone? Umów bezpłatną konsultację — przejdziemy przez nie po kolei i powiemy wprost, jeśli przy Waszej skali wystarczy jeden alert na maila i żadne wdrożenie nie jest potrzebne.
