Obsługa błędów w n8n. Zielona egzekucja nie znaczy, że zadziałało

W październiku zrobiłem przegląd własnej instancji n8n. Działa na niej kilkadziesiąt aktywnych workflowów: formularz kontaktowy tej strony, obsługa skrzynki z mailami od klientów, dane do raportów, kilka automatów z modelami AI. W ustawieniach prawie wszystkich był wpisany workflow błędów, więc byłem spokojny.

Potem otworzyłem ten workflow błędów. Składał się z jednego węzła: Error Trigger, i nic za nim. Błąd był łapany, ale nikt nie dostawał żadnej wiadomości. W drugiej firmie, w której jestem wspólnikiem, wyglądało to tak samo. W dwóch tygodniach historii znalazłem kilkanaście błędów, o których nikt nie wiedział.

Poniżej opisuję, co w n8n trzeba ustawić, żeby błąd był widoczny, i dlaczego zielona egzekucja niczego jeszcze nie dowodzi.

Workflow błędów, który naprawdę coś robi

Każdy workflow w n8n ma w ustawieniach (Settings) pole Error workflow. Wskazujesz tam osobny workflow, który zaczyna się od węzła (node) Error Trigger. Gdy egzekucja kończy się błędem, n8n uruchamia ten workflow i przekazuje mu nazwę workflowu, ostatni wykonany węzeł, komunikat błędu i link do egzekucji.

Jeden workflow błędów wystarczy na całą instancję. Ważne jest to, co stoi za Error Triggerem. U mnie teraz jest tak:

1. Węzeł Code składa z danych krótki alert: „Błąd: nazwa workflowu, węzeł”, komunikat i link do egzekucji.
2. Ten sam błąd z tego samego workflowu wysyła alert najwyżej raz na godzinę. Licznik pominiętych powtórzeń dopisuje się do następnego alertu. Bez tego jedna padnięta usługa robi z powiadomień spam i po trzecim dniu nikt ich nie czyta.
3. Alert trafia do tabeli z powiadomieniami, którą widzę na pulpicie.

Do alertu można dołożyć model AI, który z komunikatu błędu i danych z egzekucji napisze jednym zdaniem, co prawdopodobnie poszło nie tak. Przy kilkunastu błędach w tygodniu oszczędza to klikania w każdą egzekucję. Naprawę zostawiam człowiekowi. Agent, który sam poprawia workflow na produkcji, to autonomia, której przy błędach nie chcę.

Ostatni punkt listy to dalej słabe miejsce i zostawiam go tu celowo. Pulpit działa tylko wtedy, gdy na niego patrzę. Dla procesów, w których błąd kosztuje klienta (formularz kontaktowy, zamówienia, płatności), alert musi przyjść tam, gdzie go zobaczysz od razu: mailem, SMS-em albo na komunikator. Do reszty wystarczy log, który przeglądasz raz dziennie.

Ponawianie tam, gdzie błąd jest chwilowy

W ustawieniach każdego węzła jest Retry On Fail. Ustawiasz liczbę prób (Max Tries) i przerwę między nimi (Wait Between Tries). To najprostsza ochrona przed chwilowymi problemami: zewnętrzne API nie odpowiedziało, model AI był przeciążony, serwer na moment zgubił połączenie.

U mnie ponawianie miały prawie wszystkie węzły z modelami AI, ale już nie węzły HTTP do systemów, z którymi workflowy rozmawiają najczęściej. Efekt widać w historii: system telefonii w drugiej firmie zwrócił „connection refused” dziesięć razy w ciągu trzech dni. Węzeł bez ponawiania, workflow błędów bez alertu, więc dane z tych połączeń po prostu nie trafiły dalej.

Ponawianie ma jednak sens tylko przy błędach, które mogą zniknąć same. Błąd 400 (złe zapytanie) albo 401 (zły klucz) przy drugiej i trzeciej próbie będzie taki sam. Przy 429 (za dużo zapytań) dostawca mówi wprost: zwolnij. Witold Wrotek w książce „ElevenLabs. Zastosowanie w biznesie i twórczości” pisze o tym w rozdziale o limitach API, który pasuje do każdego dostawcy, nie tylko do syntezy mowy:

Limity zapytań to nie mur — to linie na jezdni. Trzymaj się ich, a pojedziesz szybciej, taniej i bezpieczniej niż zespoły, które wciąż wciskają gaz do dechy i modlą się o cud.

W n8n oznacza to: przy dużych paczkach dziel dane na mniejsze porcje (opcja batching w węźle HTTP Request albo pętla z węzłem Wait), a przerwę między próbami ustaw na tyle długą, żeby limit zdążył się odnowić.

Przy okazji sprawdź timeout. Węzeł HTTP Request ma go w opcjach, a u mnie prawie wszystkie węzły zostawały przy domyślnym. Jeśli usługa po drugiej stronie wisi, workflow wisi razem z nią, a webhook nie odpowiada stronie, która na niego czeka. Ustaw timeout krótszy niż czas, po którym druga strona i tak się podda.

On Error: opcja, która połyka błędy

Drugie ustawienie w każdym węźle to On Error. Ma trzy wartości:

Ustawienie	Co się dzieje przy błędzie	Kiedy używać
Stop Workflow	egzekucja kończy się błędem, rusza workflow błędów	domyślnie, gdy dalsze kroki bez tego węzła nie mają sensu
Continue	węzeł oddaje dane dalej, workflow jedzie, egzekucja kończy się na zielono	tylko dla kroków naprawdę pobocznych, np. zapis do logu
Continue (using error output)	węzeł dostaje drugie, czerwone wyjście, którym idzie błąd	gdy chcesz na błąd zareagować: odpowiedzieć inaczej, wysłać alert, odłożyć dane

Środkowa opcja jest najbardziej zdradliwa. Workflow przechodzi, egzekucja świeci na zielono, a workflow błędów w ogóle nie rusza, bo z punktu widzenia n8n żadnego błędu nie było.

Tak było z formularzem kontaktowym na tej stronie. Formularz wysyła dane do n8n, n8n wysyła maila przez Gmail i dopiero wtedy odpowiada stronie. Strona ma plan awaryjny: jeśli n8n nie odpowie poprawnie, wysyła maila sama. Tyle że węzeł Gmaila miał ustawione Continue. Gdyby Gmail padł, n8n i tak odpowiedziałby stronie „wszystko OK”, strona nie uruchomiłaby planu B, a wiadomość od klienta zniknęłaby bez śladu.

Teraz wysyłka maila ma czerwone wyjście. Gdy Gmail zawiedzie, n8n odpowiada stronie błędem 502 i zapisuje alert z pełną treścią zgłoszenia, więc nawet w najgorszym razie dane leżą w jednym miejscu. Jeśli Twoje workflowy przyjmują dane z formularzy, przejrzyj w nich każde Continue. Tam najczęściej chowają się ciche błędy.

Ciche błędy, których nie złapie żaden alert

Najgorsze błędy w automatyzacji to te, przy których nic nie pada. Workflow działa, egzekucje są zielone, a wynik jest zły albo pusty. Na takie przypadki workflow błędów nie pomoże, bo nie ma czego łapać. Pomaga walidacja: sprawdzenie danych, zanim pójdą dalej.

Trzy przykłady z jednego przeglądu:

1. Workflow, który dodaje cytaty z książek do mojej porównywarki, przez dwa tygodnie oznaczał część rekordów jako pominięte, bo po drugiej stronie brakowało jednego pola. Wszystko na zielono. Po poprawce trzeba było przetworzyć ponownie około 90 rekordów.
2. Skrzynka z mailami kierowała wiadomości do gałęzi „wpłata” tylko po adresie nadawcy. Serwis od wpłat wysyła z tego samego adresu też newslettery, więc newsletter wpadał do gałęzi wpłat, a ta kończyła się błędem 400, bo nie znajdowała w nim danych wpłaty. Reguła sprawdzała tylko nadawcę, a powinna sprawdzać też treść.
3. Model AI miał zwrócić odpowiedź w formacie JSON. Przy jednym mailu ze spamem zwrócił co innego, parser odrzucił wynik i zatrzymał cały workflow.

Wniosek jest za każdym razem ten sam. Zanim dane zapiszesz albo wyślesz dalej, sprawdź je węzłem IF albo Filter: czy są wymagane pola, czy kwota jest liczbą, czy model zwrócił jedną z dozwolonych wartości. To, co nie przejdzie, odkładasz do ręcznego przejrzenia. Ten sam układ opisałem przy modelu, który wybiera tylko z zamkniętej listy.

A jeśli chcesz, żeby cichy błąd stał się głośny, n8n ma na to węzeł Stop and Error. Wstawiasz go na ścieżce „dane się nie zgadzają”, on kończy egzekucję błędem i uruchamia workflow błędów. W mojej instancji używa go workflow, który zbiera raporty z Google Analytics. Gdy pobranie raportu się nie uda, błąd idzie czerwonym wyjściem prosto do Stop and Error, zamiast dopisać do zestawienia niepełne dane.

Plan B, który jedzie tym samym łańcuchem

Przy formularzu zadałem sobie jeszcze jedno pytanie: co, jeśli zawiedzie poczta, a nie n8n? Zapasowy mail ze strony też jest mailem i trafia do tej samej skrzynki. Jeśli problem leży po stronie poczty, plan B padnie razem z planem A. Dlatego zgłoszenie, przy którym coś poszło nie tak, zapisuje się dodatkowo jako alert w osobnej tabeli, poza pocztą. Nawet gdy żaden mail nie dojdzie, dane klienta zostają.

Patrick McGee w książce „Apple w Chinach” opisuje to samo w skali fabryk. Apple przenosił produkcję do Indii, żeby nie zależeć od jednego kraju:

Jeden z inżynierów produkcji tylko półżartem stwierdza, że smartfony „wyprodukowane w Indiach” są montowane w Chinach, następnie również tam rozmontowywane, po czym wysyłane do Indii w celu ponownego montażu.

W automatyzacji działa to tak samo. Zapasowy scenariusz, który woła to samo API co główny, padnie razem z nim. Dlatego plan awaryjny trzeba raz świadomie wywołać: wyłączyć główną ścieżkę i zobaczyć, czy zapasowa dowiezie wynik.

Debugowanie i ponowne uruchomienie

Gdy błąd już się zdarzy, zaczynasz od listy egzekucji (Executions) z filtrem na status błędu. W egzekucji widać dane wejściowe i wyjściowe każdego węzła, więc zwykle szybko widać, w którym miejscu dane przestały się zgadzać. Nieudaną egzekucję można ponowić, z wersją workflowu z chwili błędu albo z aktualną, już poprawioną.

Dwie rzeczy warto wiedzieć wcześniej, a nie w dniu awarii.

Po pierwsze, n8n domyślnie kasuje dane egzekucji starsze niż 14 dni (zmienna EXECUTIONS_DATA_MAX_AGE, 336 godzin). U mnie najstarsza zachowana egzekucja miała dokładnie dwa tygodnie. Jeśli błąd wyjdzie po miesiącu, nie będzie już czego oglądać. Alerty zapisuj więc poza historią egzekucji, a przy ważnych procesach wydłuż retencję.

Po drugie, ponowienie może zrobić coś drugi raz. Jeśli workflow wysłał maila i padł na zapisie do CRM, ponowienie całości wyśle drugi mail. Przy webhookach z zewnątrz warto mieć klucz, po którym rozpoznasz, że to samo zgłoszenie już przyszło, i pominąć duplikat.

Lista kontrolna dla workflowu na produkcji

1. Error workflow ustawiony w Settings i wskazuje workflow, który wysyła alert, a nie tylko go łapie.
2. Alerty z limitem powtórzeń i kanałem, który czytasz. Procesy krytyczne mają alert na telefon.
3. Retry On Fail na węzłach, które wołają zewnętrzne API i modele AI, z przerwą, która pozwala odnowić się limitowi.
4. Każde Continue w workflowie ma uzasadnienie. Jeśli błąd jest ważny, zamień Continue na czerwone wyjście, które coś z nim robi.
5. Walidacja danych przed zapisem i przed wysyłką. To, co się nie zgadza, trafia do ręcznego przejrzenia albo do Stop and Error.
6. Plan B sprawdzony w praktyce i niezależny od planu A.
7. Retencja egzekucji dopasowana do tego, jak szybko wychodzą u Ciebie błędy.
8. Webhooki z zewnątrz odporne na powtórzone wywołanie.

Ta lista działa podobnie jak automat, który pilnuje linków i pustych stron w sklepie: zamiast co kwartał szukać problemów ręcznie, ustawiasz raz mechanizm, który powie Ci o nich sam.

Kiedy to przesada

Prywatny workflow, który raz w tygodniu wrzuca coś do arkusza, nie potrzebuje kolejki, kluczy idempotencji i alertu na telefon. Wystarczy mu workflow błędów z logiem. Pełny zestaw ma sens tam, gdzie automat dotyka klienta, pieniędzy albo danych, których nie da się odtworzyć: formularze, zamówienia, płatności, CRM.

Druga pułapka to alert przy każdym węźle. Po tygodniu dziesiątek powiadomień dziennie przestajesz je czytać, a wtedy ważny alert ginie wśród reszty. Lepiej jeden workflow błędów z limitem powtórzeń i dwa kanały: pilny i dzienny.

Pierwszy krok zajmie minutę: otwórz swój workflow błędów i sprawdź, co stoi za Error Triggerem.

Masz w n8n, Make albo Zapierze automatyzacje, które dotykają klientów, a nie wiesz, co się stanie, gdy któryś krok padnie? Napisz do mnie. Zaczniemy od przeglądu jednego workflowu i listy miejsc, w których błąd może zniknąć po cichu.