Masz workflow, który działa od tygodnia bez zarzutu – a potem nagle przestaje. Klient nie dostał potwierdzenia, dane nie trafiły do arkusza, powiadomienie nie wyszło. Zaczynasz szukać: może błąd w konfiguracji? Może zewnętrzny serwis padł? Bez odpowiednich narzędzi to ślepa uliczka. Zakładka Executions w n8n to dokładnie ten instrument diagnostyczny – pełna historia każdego uruchomienia Twojego workflow, z możliwością zajrzenia do środka każdego wykonania i ponownego jego uruchomienia po naprawieniu błędu. W tym artykule pokażę jak to działa w praktyce.
Co to są Executions w n8n i do czego służą?
Execution (wykonanie) w n8n to pojedyncze uruchomienie workflow – od wyzwolenia triggera do ostatniego węzła. Każde uruchomienie jest rejestrowane i przechowywane w historii: nieważne czy skończyło się sukcesem, czy workflow wywalił się w połowie drogi.
Dlatego executions n8n pełnią rolę czarnej skrzynki Twojej automatyzacji. Kiedy coś pójdzie nie tak, nie zgadasz – wchodzisz do historii, otwierasz konkretne wykonanie i widzisz dokładnie, które węzły przetworzyły dane, co dostały na wejściu i co wysłały dalej. Tak działa debugging bez domysłów.
Executions możesz przeglądać w dwóch miejscach:
- Zakładka Executions w edytorze workflow – historia tylko tego jednego przepływu, dostępna po kliknięciu zakładki “Executions” w górnym menu edytora
- Globalna lista All Executions w bocznym menu – wszystkie wykonania ze wszystkich workflow w jednym widoku, przydatna przy monitorowaniu całego środowiska
Jak czytać zakładkę Executions – statusy i filtrowanie
Zakładka Executions w n8n wyświetla listę wierszy – każdy wiersz to jedno wykonanie workflow. Na liście widoczne są: czas startu, czas trwania, typ wyzwolenia i status. Dlatego już na poziomie listy możesz ocenić skalę problemu, zanim wejdziesz w szczegóły.
Statusy wykonań
Każde wykonanie ma jeden z czterech statusów. Success (zielony) oznacza pomyślne zakończenie. Failed (czerwony) sygnalizuje, że workflow zatrzymał się na błędzie. Running (niebieski) pojawia się przy wykonaniach trwających w tej chwili. Waiting (pomarańczowy) wskazuje, że workflow czeka na zewnętrzne zdarzenie – na przykład na odpowiedź z węzła Wait lub na akceptację w Human-in-the-Loop.
Filtrowanie po statusie jest dostępne z poziomu listy. Kiedy szukasz błędów z ostatnich 24 godzin, filtr “Failed” + zakres czasu daje natychmiastową listę wykonań wymagających uwagi – bez scrollowania przez setki udanych uruchomień.
Wykonania manualne vs produkcyjne
Na liście executions n8n odróżniasz dwa rodzaje uruchomień: manualne (wywołane przez kliknięcie “Test workflow” w edytorze) i produkcyjne (wyzwalane przez aktywny trigger – webhook, harmonogram, zdarzenie zewnętrzne). Te pierwsze są oznaczone specjalną ikonką, ponieważ służą do testowania podczas budowania. Do analizy błędów produkcyjnych skupiasz się na tych drugich.
Debug in editor – jak znaleźć przyczynę błędu krok po kroku
Debugowanie w n8n polega na tym, że otwierasz konkretne execution i widzisz dane przepływające przez każdy węzeł. To podejście eliminuje zgadywanie – zamiast spekulować, co mogło pójść nie tak, obserwujesz fakty.
Krok po kroku:
1. Znajdź problematyczne wykonanie Na liście Executions kliknij na wiersz ze statusem Failed. Otworzy się widok tego wykonania w edytorze.
2. Odczytaj gdzie workflow się zatrzymał Węzeł, który wywołał błąd, jest podświetlony czerwoną ramką. Na canvasie od razu widzisz, w którym miejscu przepływ się urwał.
3. Przejrzyj Input i Output każdego węzła Klikając w węzeł, widzisz zakładki Input (dane, które węzeł otrzymał) i Output (dane, które wysłał dalej). Przeglądasz je od lewej do prawej – szukasz miejsca, gdzie dane się “zepsuły” lub przestały odpowiadać oczekiwanemu formatowi.
4. Użyj funkcji “Debug in editor” Funkcja Debug in editor jest szczególnie przydatna, ponieważ przypina dane z błędnego wykonania bezpośrednio do edytora. Dzięki temu możesz modyfikować workflow i testować poprawki na dokładnie tych samych danych, które wywołały błąd – nie musisz czekać na kolejne prawdziwe wyzwolenie.
W praktyce debugowanie executions n8n sprowadza się najczęściej do trzech typów błędów: błędny format danych (np. tekst zamiast liczby), problem z credentials (token wygasł), lub zmiany w API zewnętrznego serwisu (inne nazwy pól w odpowiedzi). Po zlokalizowaniu przyczyny przechodzisz do naprawy i retry.
Retry w n8n – jak ponownie uruchomić workflow bez utraty danych
Retry to jeden z najbardziej praktycznych mechanizmów executions n8n, ponieważ pozwala przetworzyć te same dane ponownie – po naprawieniu błędu – bez angażowania użytkownika końcowego.
Przykład: formularz kontaktowy przesłany przez klienta wywołał workflow, który się wywalił przez błąd w logice mapowania danych. Bez retry musiałbyś prosić klienta o ponowne wypełnienie formularza. Z retry naprawiasz błąd w edytorze i uruchamiasz to samo wykonanie ponownie na zapisanych danych.
n8n oferuje dwie opcje retry:
Retry with currently saved workflow – uruchamia wykonanie ponownie z aktualną, poprawioną wersją workflow. To opcja, po którą sięgasz po naprawieniu błędu – masz pewność, że nowa logika zostanie zastosowana do starych danych.
Retry with original workflow – uruchamia wykonanie na wersji workflow, która działała w momencie błędu. Przydatne do odtworzenia problemu i potwierdzenia, że to nie zewnętrzna zmiana danych wywołała błąd, a faktycznie kod workflow.
Co więcej, n8n udostępnia zbiorczy retry – możesz zaznaczyć wiele wykonań na liście i ponownie uruchomić je wszystkie. Kiedy kilkadziesiąt wykonań failed przez tę samą przyczynę (np. chwilową niedostępność API zewnętrznego serwisu), jedno kliknięcie obsługuje wszystkie naraz.
Kurs n8n 2.0 · Kodożercy
Ile godzin tygodniowo tracisz na powtarzalne zadania?
n8n pozwala zautomatyzować to, co robisz ręcznie: przesyłanie danych, powiadomienia, raporty. Kurs n8n 2.0 na Kodożercach pokaże Ci, jak to zrobić krok po kroku, bez pisania kodu.
Sprawdź kurs n8n 2.0 →
FAQ – Najczęstsze pytania o Executions w n8n
Jak długo n8n przechowuje historię wykonań?
W wersji self-hosted czas przechowywania executions n8n konfigurujesz samodzielnie – domyślnie jest to 336 godzin (14 dni). Możesz to zmienić w ustawieniach instancji. W wersji Cloud retencja zależy od wybranego planu. Jeśli potrzebujesz długoterminowego archiwum, warto skonfigurować eksport logów do zewnętrznej bazy, bo historia wykonań to cenne źródło danych o niezawodności Twoich automatyzacji.
Czym różni się “Retry with saved workflow” od “Retry with original workflow”?
Retry with saved workflow uruchamia ponowne wykonanie z aktualną wersją workflow – czyli tą, którą właśnie zapisałeś po naprawieniu błędu. To opcja na co dzień, gdy chcesz przetworzyć stare dane nową, poprawioną logiką. Retry with original workflow używa wersji workflow sprzed zmian. Jest to przydatne do diagnozy, gdy chcesz sprawdzić czy błąd leżał w workflow czy w danych wejściowych.
Czy mogę przeglądać wykonania wszystkich workflow w jednym miejscu?
Tak – w lewym menu n8n dostępna jest sekcja “All Executions”, która agreguje executions ze wszystkich Twoich workflow. Możesz tam filtrować po statusie, zakresie czasu lub nazwie konkretnego workflow. To punkt startowy przy monitorowaniu środowiska produkcyjnego, szczególnie gdy masz kilkanaście lub kilkadziesiąt automatyzacji działających równolegle.
Podsumowanie
Executions w n8n to nie tylko log zdarzeń – to narzędzie debugowania, które zamienia każdy błąd w diagnozowalny przypadek. Zamiast zgadywać co poszło nie tak, otwierasz konkretne wykonanie, widzisz Input i Output każdego węzła i precyzyjnie lokalizujesz problem. Funkcja “Debug in editor” pozwala testować poprawki na prawdziwych danych z błędnego wykonania. Retry obsługuje ponowne przetworzenie tych danych po naprawie – bez angażowania użytkownika. Statusy Failed, Success, Waiting i Running plus filtrowanie po czasie dają pełny obraz zdrowia Twoich automatyzacji w kilka sekund. Przy skalowaniu zestawu workflow, umiejętność czytania executions n8n to jedna z pierwszych rzeczy, którą powinien opanować każdy, kto buduje produkcyjne automatyzacje.
Wróć do pełnego przewodnika: Automatyzacja w n8n – kompletny przewodnik.
