Statystyka 97% o n8n nie ma źródła. Zmierzyliśmy to sami

Jeśli czytałeś cokolwiek o niezawodności n8n, na pewno widziałeś tę liczbę. Raz dotyczy workflow, które padają na produkcji. Raz takich, które nie mają obsługi błędów. Sama liczba jest niemal zawsze ta sama: 97%.

Poszliśmy sprawdzić, skąd się wzięła. Odpowiedź brzmi: znikąd. Nie stoi za nią żadna ankieta, żaden zbiór danych, żaden pomiar. Więc zamiast powtarzać cudzą liczbę, napisaliśmy narzędzie, które mierzy to naprawdę, i przepuściliśmy przez nie 2 403 publicznie dostępne workflow n8n z dwóch niezależnie licencjonowanych zbiorów.

Przy okazji, budując to narzędzie, trafiliśmy na coś, czego najwyraźniej nikt wcześniej nie sprawdził. Najczęściej powielany publiczny korpus workflow n8n ma błąd w danych, który da się wskazać co do jednego commita. Siedzi tam od listopada 2025 i nadal jest niezałatany.

Ten tekst opisuje jedno i drugie. Anatomię statystyki, która nie istnieje, i liczby, które istnieją.

Skąd wzięła się liczba 97%

Twierdzenie krąży w dwóch wersjach i warto je rozdzielić, bo mówią o czymś zupełnie innym.

• Wersja o produkcji: „97% workflow n8n, które działają w testach, pada po wdrożeniu".
• Wersja o konfiguracji: „97% workflow n8n nie ma porządnej obsługi błędów".

Pierwszą znaleźliśmy w pakiecie treści serwisu AI Fire, czyli wideo, podcaście i wpisie blogowym z czerwca 2026, wypuszczonych przez jedną markę w dwa tygodnie. Liczbę opatrzono tam słowem „szacunkowo" i to jedno słowo dźwiga cały ciężar twierdzenia. Nie ma linku, nie ma opisu metody, nie ma zbioru danych, nie ma ankiety. Sprawdziliśmy. Przy okazji zauważyliśmy, że ten sam tekst zawiera dwie kolejne liczby bez źródła: że od 60 do 70% awarii API jest przejściowych i że uwierzytelnianie nagłówkiem eliminuje ponad 90% problemów z bezpieczeństwem webhooków. Za żadną z nich też nic nie stoi. Trzy wymyślone procenty w jednym tekście o niezawodności to co najmniej ironia warta odnotowania.

Wersja o konfiguracji chodzi po innych stronach, między innymi po tekście z datą styczeń 2026 w adresie, podpisanym przez „Jarvisa, AI operations lead", którego tożsamości nie da się zweryfikować. To już inne twierdzenie, o jakości konfiguracji, a nie o awariach po wdrożeniu, ale nosi tę samą liczbę i tak samo nie ma za sobą niczego.

Gdzie indziej ta sama figura retoryczna chodzi z liczbą 90%, a jeszcze gdzie indziej z 80%. Dziewięć sprawdzonych publikacji, dwie różne tezy, trzy różne liczby i ani jedno cytowanie, które łączyłoby je ze wspólnym źródłem. Nie ma tu łańcucha cytowań, jest równoległe powielanie tego samego chwytu z losowo dobieraną okrągłą liczbą. Tak wygląda wymyślona statystyka, gdy rozchodzi się przez content marketing. Prawdziwe pomiary nie pływają między 80 a 97 w zależności od tego, kto je akurat powtarza.

Więc przestaliśmy to powtarzać i policzyliśmy.

Co dokładnie zrobiliśmy

To analiza statyczna, nie audyt produkcji. Pobraliśmy publicznie udostępnione pliki workflow n8n i przeczytaliśmy ich JSON. Niczego nie uruchomiliśmy, nie wysłaliśmy ruchu pod cudze webhooki, nie wykonaliśmy kodu z żadnego workflow. Każda liczba niżej to policzenie konkretnego pola albo konkretnego typu node'a w konkretnym, przypiętym do commita zbiorze plików. Każdy z tych plików można pobrać samodzielnie i przeliczyć od nowa.

Te same detektory puściliśmy na dwóch zbiorach, które nie mają wspólnego autora ani wspólnej redakcji:

• Zbiór podstawowy: Zie619/n8n-workflows na licencji MIT, przypięty do commita 94007c1445d9, 2 061 plików workflow.
• Zbiór kontrolny: enescingoz/awesome-n8n-templates na licencji CC BY 4.0, przypięty do commita 728fd947, 342 pliki.

Każdy detektor czyta jedno nazwane pole i nigdy nie szuka słowa w całym pliku. Ta różnica ma znaczenie. Wcześniejszy prototyp szukał słowa „upsert" gdziekolwiek w parametrach workflow i złapał 21 żółtych karteczek, na których ktoś użył tego słowa w komentarzu. Wersja, która poszła dalej, czyta dokładnie pole parameters.operation na tym typie node'a, na którym to pole coś znaczy, i nic poza tym. Każdy detektor ma testy jednostkowe na ręcznie przygotowanych przykładach, zanim w ogóle dotknie prawdziwych danych.

Wyniki podzieliliśmy na dwa poziomy pewności i tylko jeden z nich trafia do tego tekstu jako liczba:

• Poziom A i B, podawane jako fakt. Wartość logiczna albo konkretne pole, czytane wprost, pokryte testami. Zero oceny intencji.
• Poziom C, wyłącznie kandydat, nie podajemy. Wszystko, co wymaga interpretacji (czy ten warunek naprawdę sprawdza duplikat, czy to zwykła logika biznesowa?), potrzebuje drugiego, niezależnego anotatora i rozstrzygnięcia rozbieżności przez człowieka. Tego kroku nie domknęliśmy, więc dwie kategorie, wzorce idempotencji i wzorce walidacji danych wejściowych, są z tego tekstu wyłączone w całości. Wolimy podać mniej liczb, których obronimy, niż więcej takich, których nie.

Co wyszło

Na zbiorze podstawowym, czyli 2 061 plikach zdeduplikowanych do 1 720 rodzin strukturalnych według składu typów node'ów:

„Jakikolwiek mechanizm ratunkowy" to sygnał złożony. Jest prawdziwy, gdy workflow ma gdziekolwiek ponowienie, kontynuację po błędzie albo Error Trigger. Świadomie nie wlicza jednego bardzo częstego node'a: stopAndError, który występuje w ponad połowie plików zbioru podstawowego. Ten node niczego nie ratuje, on celowo przerywa pracę i podnosi błąd. Wliczenie go do „obsługi błędów", co zrobiła wcześniejsza wersja tej samej analizy, byłoby dokładnie tym samym błędem co statystyka, którą tu obalamy: napompowaniem liczby przez policzenie czegoś innego. Mierzymy go, tylko nie nazywamy ratunkiem.

Liczba, na którą stawiamy najmocniej

Wynik dla webhooków bez uwierzytelniania to ten, którego bronimy najpewniej, bo jako jedyny przeszedł walidację krzyżową. Puszczony na zbiorze kontrolnym, z inną licencją, innym autorem i bez wspólnej historii ze zbiorem podstawowym, ten sam pomiar daje 91,2%, czyli 62 z 68 workflow zawierających webhook. Dwa zbiory, których nikt nie składał razem, zgadzają się co do 1,2 punktu procentowego w pytaniu, którego nikt wcześniej nie policzył.

Jedno zastrzeżenie, którego nie chcemy przemilczeć. W zbiorze podstawowym wartości oznaczające „uwierzytelnianie jest ustawione" wyglądają jak wyrażenia szablonowe, a nie jak prawdziwe wartości pola z działającej instancji n8n. To najpewniej ślad po narzędziu, które ten zbiór przygotowywało. Na odpowiedź „ustawione czy nieustawione" to nie wpływa, ale oznacza, że z tego zbioru nie da się odczytać, jaką metodę uwierzytelniania ktoś wybrał. Podajemy więc tylko to pierwsze.

Zestawienie z jedynym innym publicznym audytem

W maju 2026 firma AIronClaw opublikowała statyczny audyt 12 750 szablonów n8n, na który złożyło się tysiąc najczęściej oglądanych szablonów z n8n.io oraz zawartość ośmiu repozytoriów społecznościowych z GitHuba. Czytając ich metodę uważnie, znaleźliśmy tam wymienione z nazwy oba zbiory, których sami użyliśmy.

Ich wynik dla uwierzytelniania webhooków to 17,0%, czyli 2 171 z 12 750 szablonów oznaczonych jako mające webhook bez uwierzytelniania. Zestawione z naszymi 92% wygląda to na sprzeczność. Naszym zdaniem nią nie jest i warto przejść przez powód, bo to kwestia metody, a nie sporu o fakty.

Ich 17,0% liczy się względem wszystkich 12 750 szablonów, w tym mniej więcej 80 do 85% takich, które w ogóle nie mają webhooka i nigdy nie zostałyby przez ten test oznaczone, niezależnie od konfiguracji. Nasza liczba dzieli się wyłącznie przez workflow, które webhooka mają. To dwa różne mianowniki, odpowiadające na dwa różne pytania. Zgrubny rachunek pokazuje, że to się spina: jeśli webhooki występują w ich połączonym zbiorze mniej więcej tak często jak w naszym, czyli w 15 do 20% workflow, to 15 do 20% z 12 750 wypada prawie dokładnie na ich 2 171 oznaczonych szablonów. To zgodne z obrazem, w którym niemal każdy webhook w obu audytach nie ma uwierzytelniania, a dwie opublikowane liczby są tym samym faktem pokazanym na dwóch różnych podstawach. Bez ich surowego mianownika, którego nie opublikowano, nie udowodnimy tego do końca, ale arytmetyka zgadza się na tyle, że bardziej niepokojące odczytanie uważamy za bardziej prawdopodobne.

Jeszcze jedna ich liczba jest warta przywołania, bo niezależnie potwierdza decyzję, którą podjęliśmy we własnej metodzie. Ich skaner oznacza 85,7% połączonego zbioru, czyli 10 927 z 12 750, jako pozbawione obsługi błędów, z zastrzeżeniem w ich własnym opisie: n8n wymaga jawnego włączenia workflow obsługi błędów na poziomie ustawień, a większość szablonów nigdy tego nie ustawia. To bardzo prawdopodobnie to samo pole, które sami znaleźliśmy i wcześnie wyrzuciliśmy z wyników, czyli settings.errorWorkflow. Wskazuje ono na identyfikator workflow lokalny dla instancji, w której powstał, a ta referencja jest czyszczona w momencie eksportu do szablonu. To nie jest tak, że od 85 do 100% autorów postanowiło nie konfigurować obsługi błędów. To pole po prostu nie przeżywa zamiany workflow w szablon, na żadnym z obu zbiorów. Dlatego naszą główną liczbę o mechanizmach ratunkowych zbudowaliśmy z pól na poziomie node'ów. Niezależny skaner, który dochodzi do podobnie skrajnego wyniku z tej samej prawdopodobnej przyczyny, to drugie potwierdzenie, że mamy do czynienia z właściwością eksportu szablonów n8n, a nie z artefaktem jednego detektora.

Korpus, którego wszyscy używają, ma błąd, którego nikt nie zgłosił

Budując logikę deduplikacji, musieliśmy sprawdzić, czy dwa pliki workflow są strukturalnie bliźniacze, porównując ich grafy połączeń, a nie same listy node'ów. Wtedy zauważyliśmy, że pole connections w zbiorze podstawowym, czyli ta część pliku, która mówi, który node zasila który, nie robi tego, co powinno.

Policzyliśmy w tym zbiorze każdą referencję do celu połączenia. Jest ich 27 544. Z tego dokładnie 19 wskazuje na realny node po nazwie, zero po identyfikatorze, a 27 525, czyli 99,93%, prowadzi do identyfikatora w formacie error-handler-<uuid>, którego nigdzie w pliku nie ma. W 1 363 z 2 061 plików co najmniej jedno połączenie prowadzi donikąd.

Nie poprzestaliśmy na „coś tu jest zepsute". Pełna historia commitów repozytorium źródłowego jest publiczna, więc ją prześledziliśmy. Wyłom zaczyna się w jednym commicie, 5ffee225 z 3 listopada 2025, autorstwa właściciela repozytorium, z Claude jako współautorem, zatytułowanym jako zbiorcza naprawa osiemnastu otwartych zgłoszeń. Jego opis twierdzi między innymi, że „przywrócono definicje połączeń, by umożliwić import do n8n". Sprawdziliśmy to twierdzenie wprost w historii pliku. Przed tym commitem połączenia w przykładowym pliku wskazywały na node o nazwie „Error Handler for d8c07efe" i ten node istniał. W tym commicie zastąpił go inny node, ale wpis połączenia wskazujący na stary, już nieistniejący, nie został zaktualizowany. Porównaliśmy ten sam plik między tamtym commitem a commitem, do którego przypięta jest nasza analiza: identyczny co do bajta. Wyłomu nigdy potem nie tknięto. Potwierdziliśmy też, że nasz przypięty commit jest bezpośrednim potomkiem tamtej naprawy, a z 57 commitów po drodze tylko dwa dotykają czegokolwiek w plikach workflow i oba są czystym dodaniem nowych plików, bez ani jednej modyfikacji istniejących.

Prawdopodobny mechanizm widać w samym skrypcie naprawczym, który przeczytaliśmy i którego nie uruchomiliśmy. Rozpoznaje on osierocone node'y po nazwie, podczas gdy połączenia w tym korpusie są w większości plików kluczowane po identyfikatorze. Ta niezgodność po cichu unieważnia własną logikę czyszczącą skryptu dokładnie w tych plikach, w których miała zadziałać.

Nie piszemy o tym, żeby kogokolwiek zawstydzić. Repozytorium ma ponad 56 tysięcy gwiazdek i widać w nim realną, ciągłą pracę utrzymaniową, łącznie z udokumentowaną, podjętą w dobrej wierze próbą naprawienia właśnie tego problemu. Chodzi o coś węższego i, naszym zdaniem, bardziej użytecznego. Ten zbiór jest wykorzystywany jako materiał źródłowy przez co najmniej jedną inną publiczną analizę, na którą trafiliśmy, i wchodzi w skład połączonego korpusu 12 750 szablonów z jedynego audytu, z którym się wyżej zestawiamy. O ile jesteśmy w stanie stwierdzić, nikt nie sprawdził, czy sam graf połączeń jest wiarygodny, zanim zaczął w nim cokolwiek liczyć. Ten sam test puściliśmy na zbiorze kontrolnym, z inną licencją, innym właścicielem i bez wspólnej historii, i dostaliśmy zero zepsutych referencji na ponad 4 300. Cokolwiek się tu wydarzyło, jest właściwością historii tego jednego repozytorium, a nie tego, jak n8n eksportuje szablony.

Praktyczny wniosek: każda statystyka wyciągnięta z topologii workflow w tym zbiorze, czyli z tego, który node prowadzi do którego albo czy warunek stoi za punktem wejścia, jest na tych danych niewiarygodna. Kropka. Statystyki z pól pojedynczych node'ów, czyli czy ten node ma ustawione retryOnFail i czy ten webhook ma wartość uwierzytelniania, są tym nietknięte, bo te pola nie zależą od poprawnego rozwiązania się grafu połączeń. Sprawdziliśmy zresztą osobno, że raportowane przez nas pola dają identyczny wynik niezależnie od tego, czy grupujemy po pojedynczych plikach, czy po zdeduplikowanych rodzinach strukturalnych. Ale częstość stopAndError i wszystko, co ma kształt połączeń, podajemy wyłącznie jako właściwość tego konkretnego zbioru, a nie jako fakt o workflow n8n w ogóle.

Czego świadomie nie twierdzimy

• Odsetka idempotencji i walidacji danych wejściowych. Oba są u nas na poziomie C, czyli to strukturalnie wykryci kandydaci, którzy nie przeszli jeszcze weryfikacji drugiego anotatora i rozstrzygnięcia przez człowieka. Nie publikujemy liczby, której na dziś nie obronimy.
• Tego, jak ludzie naprawdę używają n8n na produkcji. Każda liczba tutaj opisuje publikowane szablony, czyli punkt startowy, który ktoś kopiuje, a nie stan po tym, jak realny zespół to skonfiguruje, zabezpieczy i uruchomi. Szablony pokazują dolną granicę włożonej pracy, nie przekrój działających systemów.
• Jednej zbiorczej „oceny niezawodności n8n". Każdy wymiar podajemy na jego własnym mianowniku i robimy to celowo. Workflow bez webhooka nie może mieć webhooka bez uwierzytelniania, a zwinięcie tego w jedną liczbę to dokładnie ten błąd kategorii, który wyprodukował 97%.

Co z tego wynika, jeśli masz n8n w firmie

Trzy rzeczy do sprawdzenia w swoich przepływach, po kolei, bez czytania kodu.

• Co się dzieje, gdy zewnętrzny system nie odpowie. W publikowanych szablonach odpowiedź brzmi zwykle „nic", bo tylko 5,2% ma ustawione ponawianie. Jeśli Twój przepływ pobiera dane z API dostawcy albo wysyła fakturę do systemu księgowego, jedna chwilowa awaria po drugiej stronie ma nie kasować całego przebiegu.
• Kto się dowie, że coś padło, i po ilu godzinach. Osobny node Error Trigger, czyli mechanizm, który w razie awarii wysyła powiadomienie, ma mniej niż jeden procent szablonów. Automatyzacja, która milczy, gdy przestaje działać, jest groźniejsza od jej braku, bo przez tydzień wszyscy zakładają, że robota się dzieje.
• Kto może wywołać Twój przepływ. Webhook to adres, pod który żądanie wyśle każdy, kto go zna. Jeśli uruchamia zapis do bazy, wysyłkę maila albo cokolwiek, co kosztuje, ma być za uwierzytelnianiem. W publikowanych szablonach nie jest w ponad dziewięciu przypadkach na dziesięć.

Jeśli chcesz zobaczyć, ile kosztuje zrobienie tego porządnie od początku, opisaliśmy to osobno we wpisie o tym, ile kosztuje automatyzacja n8n. Zasady, na których pracujemy, czyli własny serwer klienta, klucze po jego stronie i eksport przepływów w jego repozytorium, opisaliśmy w sekcji usługi.

Jak to powtórzyć u siebie

Pakiet detektorów, skrypt pobierający zbiory z przypiętymi identyfikatorami commitów oraz pełny opis ustalenia o grafie połączeń są otwarte: github.com/adix65/n8n-reliability.

python3 -m n8n_reliability.cli fetch-corpus --dest data/corpus/n8n-workflows
python3 -m n8n_reliability.cli analyze --corpus-dir data/corpus/n8n-workflows --out-dir out

Każda liczba w tym tekście ma licznik, mianownik i zapisane zwykłym językiem wyjaśnienie, czym ten mianownik jest. Jeśli któregoś procentu z tego artykułu nie da się sprowadzić do tych trzech rzeczy, potraktuj to jako błąd w artykule, a nie jako fakt o n8n.

Jeśli masz u siebie przepływy n8n i chcesz wiedzieć, które z nich milczą, gdy padają, napisz do nas. Przejdziemy przez nie na Twoich danych, na bezpłatnej rozmowie.

SEVENEDGE buduje i utrzymuje automatyzacje n8n na serwerach klientów, obok programów pisanych na zamówienie. Ten tekst jest analizą statyczną publicznie udostępnionych plików workflow, a nie twierdzeniem o systemie któregokolwiek klienta.