Dlaczego workflow n8n nie działa i jak znaleźć przyczynę?

Gdzie szukać najpierw i czego nie widać w Executions?

Zakładka Executions to pierwszy przystanek przy każdej awarii. Widać w niej status każdego uruchomienia, węzeł, na którym się zatrzymało, i pełne dane wejściowe każdego kroku aż do miejsca błędu. To wystarcza w większości przypadków: klikasz czerwoną egzekucję, otwierasz węzeł, patrzysz, co dostał na wejściu, i zwykle od razu widać, że pole było puste albo miało zły typ.

Executions nie pokazuje jednak trzech rzeczy, które regularnie mylą ludzi.

Po pierwsze, nie pokazuje tego, co się nigdy nie uruchomiło. Jeśli trigger nie odpalił, bo webhook nie doszedł albo harmonogram nie zadziałał z powodu złej strefy czasowej na serwerze, w Executions nie ma po tym śladu. Trzeba sprawdzić sam trigger osobno: dla webhooka to test w Postmanie albo curl, dla harmonogramu to godzina serwera przez węzeł Code z new Date().

Po drugie, jeśli w Settings workflowu wyłączone jest zapisywanie egzekucji, zakładka jest po prostu pusta, mimo że workflow działa i coś robi w tle. To ustawienie ma sens na workflowach o wysokim wolumenie, gdzie każda egzekucja dopisywałaby rekord do bazy i po tygodniach zapychała dysk. Ale jeśli włączysz je od razu, przy pierwszym uruchomieniu na produkcji, odbierasz sobie możliwość debugowania. Wyłączaj zapis dopiero wtedy, gdy workflow przeszedł testy i chcesz go zostawić w spokoju.

Po trzecie, czerwona egzekucja nie zawsze znaczy błąd w sensie technicznym. Węzeł IF, który poszedł w gałąź false, bo dane nie spełniły warunku, to zwykle poprawne zachowanie, nie awaria. Zanim zaczniesz szukać przyczyny, sprawdź, czy to w ogóle powinno być inaczej.

Dlaczego agent (albo klient) w ogóle nie łączy się z n8n?

To osobna kategoria problemów, bo wszystko dzieje się, zanim workflow w ogóle ruszy. Telemetria agentów AI, które budują workflowy w n8n, pokazuje, że 43% testów połączenia z API n8n kończy się błędem. Rozkład przyczyn jest nierówny: 76% to błędy adresu albo nieosiągalnej sieci, dalej błędna ścieżka API, a na końcu brak odpowiedzi w ogóle.

W praktyce sprowadza się to do kilku pytań, które zadaję po kolei.

Czy adres jest poprawny? Najczęstsza pomyłka to URL bez /api/v1 na końcu albo z http zamiast https, albo z adresem edytora zamiast adresu API instancji. Jeśli n8n stoi za reverse proxy, adres wewnętrzny i zewnętrzny bywają różne, a agent czasem dostaje ten pierwszy.

Czy sieć w ogóle widzi instancję? Jeśli n8n działa w sieci wewnętrznej albo za VPN, a agent próbuje połączyć się z zewnątrz, dostanie timeout albo odmowę połączenia, co telemetria klasyfikuje jako błąd adresu, bo z punktu widzenia klienta wygląda identycznie jak zły URL.

Czy ścieżka API jest aktualna? Rzadszy, ale realny przypadek: n8n po aktualizacji zmienia strukturę niektórych endpointów, a stary klient próbuje starej ścieżki i dostaje odpowiedź NOT_FOUND zamiast danych.

Bardzo konkretny przypadek widziałem u klienta: agent dostawał błąd 403 przy próbie pobrania listy credentiali, mimo że klucz API działał wcześniej bez problemu. Klucz powstał przed aktualizacją n8n, która wprowadziła nowy, bardziej granularny poziom uprawnień API. Stary klucz miał uprawnienia sprzed zmiany i nie obejmował nowego zasobu. Naprawa: Settings, n8n API, Rotate, nowy klucz z pełnymi uprawnieniami. Od tamtej pory ustawiam klucze z wygasaniem po 90 dniach, żeby ten sam problem nie wrócił po kolejnej aktualizacji i żeby ktoś musiał świadomie odnowić dostęp, zamiast trzymać klucz sprzed dwóch lat.

Dlaczego workflow psuje się w węźle, który wcześniej działał?

Jeśli konfiguracja węzła się nie zmieniła, a węzeł przestał działać, przyczyna leży zwykle poza workflowem.

Model językowy został wycofany. Widziałem to dwukrotnie: raz Google wycofał serię Gemini 2.5 i workflow, który jej używał, zaczął zwracać błędy zamiast odpowiedzi, drugi raz dwuletni projekt klienta przestał działać, bo Anthropic wycofał Haiku 3. Naprawa jest prosta, wystarczy zmienić model w węźle, ale trzeba się o wycofaniu dowiedzieć, zanim workflow zacznie krzyczeć. Przegląd używanych wersji modeli raz na kwartał to teraz stały punkt w utrzymaniu każdej automatyzacji z węzłem LLM.

Nowa wersja modelu jeszcze nie jest obsługiwana przez węzeł. Odwrotna sytuacja: dostawca wypuszcza świeży model, ktoś go wybiera z listy, a węzeł n8n dla tego dostawcy zwraca błąd w stylu „Malformed function call”, bo format odpowiedzi nowego modelu różni się od tego, czego węzeł oczekuje. To zwykle kwestia dni albo tygodni, zanim n8n dogoni zmianę. Do tego czasu zostań przy poprzedniej wersji modelu.

Ciasteczka wygasły. Częsty przypadek w workflowach, które scrapują aplikację bez publicznego API przez węzeł HTTP Request z ciasteczkami sesji zaszytymi w credentialach. Sesja wygasa po jakimś czasie, a węzeł zaczyna dostawać stronę logowania zamiast danych. Rozwiązanie, które sprawdza się u mnie: error output z tego węzła leci do powiadomienia, ciasteczka trzymam w Data Table zamiast na sztywno w węźle, a osobny workflow odświeżający loguje się cyklicznie i aktualizuje wpis w tabeli.

Dane ze źródła zmieniły kształt. Arkusz Google dostał nową kolumnę, API zmieniło nazwę pola w odpowiedzi, formularz zyskał nowe pytanie. Węzeł działający na sztywnych indeksach albo nazwach pól się wywraca. To nie błąd n8n. Automatyzacja zakłada stały kształt danych, a coś po drugiej stronie zmieniło go bez ostrzeżenia.

Dlaczego węzeł AI Agent halucynuje albo zwraca bzdury?

Najczęstsza przyczyna, jaką widzę w workflowach budowanych bez doświadczenia z n8n: instrukcja opisująca, jak agent ma pracować, trafia do wiadomości użytkownika, a system message zostaje pusty albo z domyślnym „you are a helpful assistant”. Model nie ma wtedy stałego kontekstu działania: dostaje instrukcję razem z danymi w jednej wiadomości. Jakość spada, nawet jeśli ten sam tekst promptu działa dobrze w zwykłym czacie. Zasada jest prosta: system message opisuje, jak agent ma pracować, user message zawiera tylko dane do przetworzenia.

Druga częsta przyczyna to Data Table „If row exists” zwracający pusty obiekt zamiast oczekiwanego wyniku. Agent dostaje coś, co wygląda jak brak danych, choć wiersz istnieje, i zaczyna zgadywać albo twierdzić, że danych nie ma.

Trzecia to twardy limit 4 kB na odpowiedź narzędzia w n8n Agents. Jeśli podłączone narzędzie zwraca surową stronę HTML ze scrapera albo cały wiersz danych zamiast streszczenia, odpowiedź się ucina. Dla agenta wygląda to jak narzędzie, które nie działa, mimo że sub-workflow wykonał się poprawnie. Rozwiązanie: narzędzie zwraca przetworzony tekst, nie surowe dane.

Dlaczego nikt nie zauważa cichych awarii?

To najgorszy wariant, bo nikt nie wie, że jest problem, dopóki go przypadkiem nie znajdzie. U jednego klienta workflow przestał działać po zmianie po stronie zewnętrznego API i nikt tego nie zauważył przez dwa tygodnie, bo nikt nie miał powodu otwierać zakładki Executions codziennie. Klient zorientował się dopiero wtedy, gdy braki w danych wyszły na jaw gdzie indziej.

To jest dokładnie ten scenariusz, przed którym chroni error workflow: bez niego informacja o awarii istnieje wyłącznie w Executions i tylko dla kogoś, kto tam zajrzy. Z error workflow informacja sama przychodzi do człowieka, w kilka sekund po awarii, kanałem, który i tak sprawdza codziennie: czat zespołu, task w menedżerze zadań, mail.

Inny wariant cichej awarii to trigger, który nigdy się nie uruchamia. Harmonogram ustawiony w złej strefie czasowej odpala się o trzeciej w nocy zamiast o dziewiątej rano, kiedy dane jeszcze nie są gotowe, i workflow kończy się bez błędu, ale z pustym wynikiem. Sprawdzaj raz na jakiś czas faktyczną godzinę uruchomienia, nie tylko konfigurację harmonogramu.

Które zachowania n8n zaskakują najczęściej?

Kilka mechanizmów n8n działa inaczej, niż intuicja podpowiada, i regularnie powoduje te same błędy.

Execute Workflow z węzłem Wait w sub-workflowie. Jeśli sub-workflow wywołany przez Execute Workflow zawiera Wait, dane po wznowieniu mogą nie wrócić poprawnie do workflow nadrzędnego. Zamiast Wait w sub-workflowie lepiej zbudować wzorzec oparty na webhooku.

SplitInBatches z Wait w tej samej pętli. Stan iteratora nie przetrwa oczekiwania, więc elementy bywają pomijane albo przetwarzane drugi raz. Batch najlepiej przetwarzać synchronicznie albo przez kolejkę.

Append w Google Sheets na arkuszu z kolumnami formuł. Operacja append wpisuje surowe wartości, łącznie z wynikiem formuły zapisanym jako zwykły tekst, i nadpisuje formułę na stałe. Update z konkretnym zakresem komórek jest bezpieczniejszy tam, gdzie arkusz liczy coś sam.

$env niedostępne w węźle Code. To celowe ograniczenie bezpieczeństwa, nie błąd. Zmienne środowiskowe trzeba przekazać inną drogą, na przykład przez dane wejściowe workflowu albo statyczne dane workflowu.

saveExecutionProgress zapełnia dysk. Ta opcja zapisuje stan po każdym węźle, co ma sens przy krytycznych workflowach wymagających wznowienia, ale przy dużym wolumenie potrafi w kilka dni zapełnić dysk. Sprawdź dostępne miejsce, zanim ją włączysz.

Gałęzie IF to „true” i „false”, nie numery. Przy łączeniu węzłów po IF trzeba się odwoływać do nazwanej gałęzi, nie do numeru wyjścia. Switch działa podobnie, z nazwami odpowiadającymi regułom.

$input.all() kontra $input.first(). Branie tylko pierwszego elementu, gdy na wejściu jest ich więcej, to klasyczny błąd w węźle Code. Przy wielu elementach potrzebne jest $input.all() z iteracją albo tryb uruchamiania osobno dla każdego elementu.

Przetwarzanie po jednym elemencie na dużych zbiorach. Węzeł Google Sheets domyślnie odpytuje API osobno dla każdego wiersza. Przy stu i więcej wierszach to wolne i łatwo trafić w limit zapytań. Operacje wsadowe albo Append or Update z wieloma wierszami naraz działają dużo szybciej.

Odpowiedź webhooka trzeba wysłać jawnie. Przy trybie Using Respond to Webhook Node workflow musi mieć węzeł Respond to Webhook, inaczej wywołujący czeka do timeoutu. Do prostych potwierdzeń wystarczy tryb When Last Node Finishes.

Error Trigger musi być w osobnym workflowie. Nie złapie błędów we własnym workflowie. Musi żyć w dedykowanym workflowie do obsługi błędów, podłączonym przez Settings, Error Workflow, w każdym workflowie, który ma być monitorowany.

$getWorkflowStaticData('global') w pętlach. Jeśli pętla idzie przez Code, HTTP Request, Code, If i z powrotem do HTTP Request, węzeł HTTP Request nadpisuje $json odpowiedzią z API, więc licznik iteracji albo zgromadzone dane trzymane w $json giną. Stan pętli trzeba trzymać w statycznych danych workflowu. Trzeba je też czyścić na początku każdego uruchomienia, bo inaczej zostają w bazie między uruchomieniami i stare dane z nieudanej egzekucji mogą przeciekać do kolejnej.

Jak ustawić error handling na trzech poziomach?

To układ, który stosuję w każdym workflowie produkcyjnym u klientów i który wyłapuje niemal wszystko, zanim zdąży zamienić się w cichą awarię.

Poziom pierwszy: Retry on Fail na każdym węźle łączącym się z usługą zewnętrzną. Google Drive, Google Sheets, dowolne API. Trzy próby z odczekaniem między nimi łapią zdecydowaną większość przejściowych awarii: chwilowy timeout, moment przeciążenia po drugiej stronie, krótką przerwę w sieci. To najtańszy poziom ochrony i powinien być domyślny, nie wyjątek.

Poziom drugi: On Error ustawiony na Continue using error output dla błędów, których się spodziewasz. Zamiast zatrzymywać cały workflow, węzeł dostaje czerwone wyjście error output, które można podłączyć dalej. Ja podłączam je do powiadomienia na czacie zespołu z nazwą węzła i treścią błędu, więc wiadomo dokładnie, co i gdzie się wywróciło, bez otwierania Executions.

Poziom trzeci: osobny error workflow dla błędów nieoczekiwanych. Ustawiasz go w Settings workflowu, w polu Error Workflow, w każdym workflowie produkcyjnym z osobna. Sam error workflow zaczyna się od węzła Error Trigger i ma dwa zadania: odsiać szum i przekazać sygnał do człowieka. Filtr na początku odrzuca błędy przejściowe, takie jak chwilowy timeout albo moment niedostępności Google Drive, żeby nie zalewać zespołu powiadomieniami o czymś, co samo się naprawi przy kolejnej próbie. To, co przejdzie przez filtr, trafia równolegle w dwa miejsca: zadanie w menedżerze zadań zespołu przypisane do właściciela workflowu i alert na kanał Google Chat przez webhook przychodzący.

Który workflow potrzebuje tego trzeciego poziomu? Każdy aktywny, uruchamiany harmonogramem albo webhookiem, który robi coś realnego, a nikt nie patrzy na wynik na żywo. Workflow interaktywny, który uruchamiasz ręcznie i obserwujesz w edytorze podczas testów, może się bez niego obejść, bo błąd widać od razu na ekranie.

Jak debugować przez agenta AI, nie robiąc bałaganu w systemach?

Kilka nawyków, które sprawdzają się przy debugowaniu z pomocą agenta, na przykład przez n8n-mcp, bez ryzyka, że agent coś realnie popsuje w trakcie testów.

Wyłączaj węzły akcji klawiszem D, zanim puścisz test. Dane płyną przez cały workflow, ale nic nie trafia do zewnętrznych systemów: żaden mail nie wyjdzie, żaden rekord się nie zapisze. Można testować dowolną liczbę razy bez efektów ubocznych, a agent widzi pełny przepływ danych łącznie z miejscem, gdzie coś się psuje.

Loguj wyniki do Data Table zamiast ręcznie przeglądać egzekucje. Uruchamiasz workflow w trybie cienia przez kilka dni, każdy przebieg dopisuje wiersz z wejściem, wyjściem i statusem, a potem agent dostaje polecenie przejrzenia tabeli i wskazania, gdzie prompt albo logika wymaga poprawki. To dużo szybsze niż klikanie po Executions jedna po drugiej.

Zbuduj zestaw w zakładce Evaluations dla workflowów z węzłem modelu. To testy regresyjne dla promptu: zestaw zapytań uruchamiany po każdej zmianie, z punktacją jakości, więc widać od razu, czy poprawka pomogła, czy zepsuła coś innego. Przez n8n-mcp agent potrafi zbudować taki zestaw sam na podstawie opisu, co workflow ma robić.

Po każdej aktualizacji n8n rób twardy refresh, Ctrl albo Cmd plus Shift plus R. Interfejs czasem pokazuje stan sprzed aktualizacji, dopóki cache przeglądarki się nie wyczyści, co wygląda jak błąd w workflowie, choć to tylko stara wersja UI.

I na koniec, jeśli agent debuguje na produkcyjnej instancji, upewnij się, że zapis egzekucji jest włączony, zanim zacznie. Bez tego agent dostaje tyle samo informacji co człowiek patrzący na pustą zakładkę: żadnej.