Dlaczego automatyzacje n8n przestają działać — i jak to wykryć zanim zauważy klient

Trzy rodzaje awarii, które wyglądają zupełnie inaczej

Warto je rozdzielić, bo każdy wymaga innego zabezpieczenia, a większość wdrożeń chroni się tylko przed pierwszym.

• Awaria głośna — wykonanie kończy się błędem, jest czerwony wpis w historii. Najłatwiejsza, bo widoczna od razu.
• Awaria cicha — wykonanie kończy się sukcesem, ale przetwarza zero rekordów. Filtr przestał cokolwiek przepuszczać, bo zmieniła się nazwa pola w źródle. Panel jest zielony, a proces nie działa.
• Awaria powolna — workflow działa, tylko coraz wolniej albo coraz rzadziej. Zwykle efekt limitów API po drugiej stronie albo rosnącej liczby rekordów w każdym przebiegu.

Cicha jest najkosztowniejsza. W automatyzacji obsługi zgłoszeń oznacza tygodnie niewysłanych powiadomień, o których dowiadujesz się od klienta, a nie z systemu.

Przyczyna numer jeden: poświadczenia, nie logika

Workflow zbudowany raz i przetestowany zwykle nie psuje się sam z siebie. Psuje się jego otoczenie — a najkrótszy termin ważności mają połączenia z zewnętrznymi usługami.

Tokeny OAuth wygasają albo zostają unieważnione, gdy ktoś zmieni hasło do konta Google, cofnie zgodę aplikacji w panelu administracyjnym albo odejdzie z firmy i jego konto zostanie zablokowane. Automatyzacja podpięta pod prywatne konto pracownika przestaje działać w dniu jego odejścia — i to jest scenariusz, który widujemy najczęściej.

Praktyczny wniosek dla wdrożenia: integracje podpinaj pod konta serwisowe firmy, nie pod konta imienne. Koszt tego jest zerowy w dniu wdrożenia i bardzo wysoki pół roku później.

Pułapka, o której nie mówi się przy wdrożeniu: błąd w wyzwalaczu

n8n pozwala wskazać dla każdego workflow osobny workflow obsługi błędu — ustawia się go w ustawieniach workflow, a sam workflow-obsługa musi zaczynać się węzłem Error Trigger. Jeden taki workflow może obsługiwać wszystkie pozostałe, więc to kilkanaście minut pracy, które warto poświęcić przy każdym wdrożeniu.

Jest jednak istotne zastrzeżenie, wprost opisane w dokumentacji n8n: jeśli błąd wystąpi w węźle wyzwalacza, do obsługi błędu trafia inny, uboższy zestaw danych. Nie ma w nim identyfikatora wykonania ani odnośnika do niego — po prostu dlatego, że wykonanie nigdy się nie rozpoczęło i nie ma czego zapisać w bazie.

To odwrotność intuicji. Awarie wyzwalacza — czyli właśnie te od wygasłych poświadczeń i niedziałających webhooków — są jednocześnie najczęstsze i najsłabiej udokumentowane w alertach. Alert przychodzi, ale bez odnośnika, w który można kliknąć.

Historia wykonań znika po 336 godzinach

To ustawienie zaskakuje przy pierwszej poważnej diagnozie. n8n domyślnie czyści dane starych wykonań na bieżąco: zmienna EXECUTIONS_DATA_PRUNE jest domyślnie włączona, a EXECUTIONS_DATA_MAX_AGE wynosi 336 godzin, czyli równo czternaście dni. Osobno działa limit liczby: EXECUTIONS_DATA_PRUNE_MAX_COUNT to domyślnie 10 000 zachowanych wykonań.

Konsekwencja jest praktyczna: jeśli automatyzacja przestała działać trzy tygodnie temu, a zauważyliście to dzisiaj, to nie ma już w bazie ani jednego wykonania z okresu, w którym coś się zepsuło. Zostaje odtwarzanie po skutkach — czyli po tym, czego nie ma w CRM-ie.

Przy dużym wolumenie szybciej zadziała limit liczby niż limit wieku: 10 000 wykonań przy workflow uruchamianym co pięć minut to nieco ponad miesiąc, ale przy pięciu takich workflow — tydzień. Warto policzyć to dla swojej instalacji, zanim będzie potrzebne.

Zmiany po stronie dostawców API

Druga kategoria przyczyn jest całkowicie poza Waszą kontrolą. Dostawcy wyłączają starsze wersje API, zmieniają nazwy pól w odpowiedziach, zaostrzają limity zapytań albo wprowadzają nowe wymogi uwierzytelniania. Workflow, który nie zmienił się ani o jeden węzeł, przestaje działać, bo zmieniło się to, z czym rozmawia.

Zmiana nazwy pola jest tu najbardziej podstępna, bo nie powoduje błędu. Węzeł odczytuje nieistniejące pole, dostaje pustą wartość i przepuszcza ją dalej. Rekord powstaje, tylko bez adresu e-mail. To jest dokładnie ta cicha awaria z początku tekstu.

Co realnie zabezpiecza automatyzację

Kolejność ma znaczenie — pierwsze dwa punkty dają największy efekt przy najmniejszym nakładzie.

• Jeden wspólny workflow obsługi błędu podpięty do wszystkich pozostałych, wysyłający alert tam, gdzie ktoś realnie patrzy — na Slacka albo na skrzynkę zespołu, nie na adres, który obsługuje jedna osoba na urlopie.
• Monitoring efektu, nie stanu. Zamiast sprawdzać, czy workflow jest aktywny, sprawdzaj, czy w ciągu ostatnich 24 godzin powstał choć jeden rekord, który miał powstać. Osobny workflow z harmonogramem, który liczy wyniki i alarmuje przy zerze, wykrywa ciche awarie — a nic innego ich nie wykryje.
• Ponawianie tylko tam, gdzie ma sens. Ustawienie ponawiania na węźle ratuje przy chwilowych błędach sieci i limitach zapytań. Nie ratuje przy błędnych danych — tam trzykrotne ponowienie tylko trzykrotnie powtórzy ten sam błąd.
• Rejestr integracji i ich właścicieli. Prosta tabela: workflow, z czym się łączy, na jakim koncie, kto jest właścicielem. Przy odejściu pracownika albo zmianie dostawcy od razu wiadomo, co sprawdzić.
• Przegląd raz na kwartał. Piętnaście minut na przejrzenie listy wykonań każdego workflow: czy liczby zgadzają się z oczekiwaniami, czy czasy nie rosną, czy nie ma serii błędów zignorowanych przez ponawianie.

Ile to kosztuje w praktyce

Utrzymanie jest tą częścią wdrożenia, którą najłatwiej pominąć w wycenie i najdrożej odzyskać później. Zabezpieczenia z listy powyżej to zwykle kilka godzin pracy przy wdrożeniu i kilkadziesiąt minut kwartalnie na przegląd — nieporównywalnie mniej niż odtwarzanie trzech tygodni brakujących danych w CRM.

Jeśli szukacie kosztów samego wdrożenia, rozpisaliśmy je w tekście ile kosztuje wdrożenie n8n. Kwestię tego, gdzie n8n postawić, omawiamy w porównaniu self-hosted czy cloud — a konkretne scenariusze automatyzacji zebraliśmy w 12 przykładach automatyzacji w firmie.