Automatyzacja w n8n pada po 3-6 miesiącach. Dlaczego (i jak to wyłapać, zanim zgłosi to klient)

Automatyzacja nie psuje się sama, tylko świat wokół niej się zmienia

W większości poradników o n8n czy Make skupiamy się na budowie pierwszego scenariusza: podłącz webhook, dodaj węzeł, przetestuj, gotowe. To jest łatwa część. Problem zaczyna się dużo później, w momencie, którego nikt nie dokumentuje, bo nie jest "sexy" do pokazania w case study.

Z naszego utrzymania wdrożeń u klientów wynika jedno: automatyzacja, która działała bezbłędnie od wdrożenia do miesiąca trzeciego, nie znaczy, że będzie działać w miesiącu siódmym. Nie zmienia się kod scenariusza. Zmienia się wszystko wokół niego: API dostawcy, limity konta, struktura arkusza, ważność tokenu. Automatyzacja jest tylko tak stabilna, jak najsłabsze ogniwo w integracjach, na których stoi, a te ogniwa żyją swoim życiem niezależnie od tego, co zbudowaliśmy.

Dlatego nie zgadzam się z podejściem "wdrożyliśmy, działa, można zapomnieć". To jest prosta droga do sytuacji, w której klient firmy pisze "dlaczego nie dostałem potwierdzenia zamówienia od trzech dni", a w firmie nikt nie wie, że automatyzacja stoi od tygodnia.

Pięć przyczyn, przez które scenariusz pada, i które widzimy najczęściej

To nie jest lista teoretycznych ryzyk. To powtarzalny wzorzec z realnych wdrożeń: te same pięć rzeczy wracają u różnych klientów, w różnych branżach, z różnymi narzędziami.

1. Token OAuth wygasa, a nikt go nie odnawia

Integracje z Google, Microsoft, bankami czy systemami księgowymi najczęściej działają na OAuth z tokenem odświeżającym. Problem: część dostawców wymusza ponowną autoryzację po określonym czasie, niezależnie od tego, czy refresh token teoretycznie powinien działać bez końca. Konto, na którym zbudowano połączenie, zmienia hasło, administrator traci dostęp, albo dostawca po swojej stronie unieważnia sesję przy zmianie zasad bezpieczeństwa. Scenariusz, który do tej pory bezgłośnie odświeżał dane, zaczyna zwracać błąd autoryzacji. Bez alertu ten błąd leży w logach n8n albo Make i czeka, aż ktoś go przypadkiem zobaczy.

2. Dostawca zmienia swoje API, nie ostrzegając nikogo

Allegro, banki, systemy ERP regularnie aktualizują swoje API. Czasem to zmiana wersji endpointu, czasem zmiana formatu odpowiedzi, czasem po prostu wycofanie pola, z którego scenariusz korzystał od początku. Rzadko kiedy dostawca wysyła maila do każdej firmy korzystającej z integracji z informacją "za dwa tygodnie zmieniamy strukturę odpowiedzi". Jeśli scenariusz nie ma wersjonowania zapytań i nie sprawdza, czy odpowiedź wygląda tak, jak powinna, to pierwszy sygnał, że coś się zmieniło, to błąd w środku procesu, często w nocy albo w weekend.

3. Limit operacji w planie cenowym się kończy

Plany cenowe n8n i Make liczą operacje albo wykonania workflow. Firma rośnie, liczba zamówień czy faktur rośnie, a plan zostaje ten sam, bo nikt nie wrócił do konfiguracji po trzech miesiącach od wdrożenia. W pewnym momencie scenariusz przestaje się wykonywać w połowie miesiąca, bo limit się wyczerpał. To jeden z najbardziej frustrujących scenariuszy, bo z zewnątrz wygląda jak awaria, a w rzeczywistości to kwestia planu, którą da się rozwiązać w pięć minut, jeśli ktoś wie, że trzeba.

4. Struktura danych w arkuszu lub ERP się zmienia

Ktoś w księgowości dodaje nową kolumnę do arkusza rozliczeniowego. Ktoś w dziale handlowym zmienia nazwę statusu zamówienia w systemie ERP po aktualizacji. Scenariusz, który odwoływał się do konkretnej kolumny czy konkretnej wartości, nagle dostaje dane w innym formacie, albo nie dostaje ich wcale. To jedna z tych awarii, których nie da się przewidzieć na etapie wdrożenia, bo przyczyna leży poza automatyzacją: w decyzji operacyjnej podjętej przez kogoś, kto nie wie, że ta kolumna jest używana przez workflow.

5. Brak alertów o błędach w samym scenariuszu

To nie jest przyczyna awarii, to przyczyna tego, że awaria trwa tygodniami, zamiast godzin. Domyślnie n8n i Make nie krzyczą do nikogo, kiedy workflow się wywali. Błąd ląduje w historii wykonań, widocznej tylko dla kogoś, kto zaloguje się i sprawdzi. Jeśli nikt nie sprawdza, bo "działa, to działa", to pierwsza osoba, która dowiaduje się o problemie, to klient, który nie dostał faktury, potwierdzenia albo odpowiedzi na zapytanie.

Okno 3-6 miesięcy: dlaczego klienci zgłaszają awarię dopiero wtedy

Z obserwacji wdrożeń wynika dość konkretny wzorzec czasowy. Pierwszy miesiąc po wdrożeniu scenariusz jest pod lupą: wszyscy sprawdzają, czy działa, poprawiają drobne niedociągnięcia, reagują szybko. Potem uwaga spada, bo nic się nie dzieje, automat po prostu robi swoje. Właśnie w tym momencie, między trzecim a szóstym miesiącem, pojawia się pierwsza zmiana po stronie dostawcy, pierwszy wygasający token albo pierwszy miesiąc, w którym liczba operacji przekroczyła limit planu. To nie przypadek, że tak dużo zgłoszeń "automatyzacja się wysypała" pojawia się właśnie w tym oknie: to po prostu czas, w którym kumuluje się kilka niezależnych zmian zewnętrznych, a wewnętrzna czujność już spadła do zera.

Jeśli ktoś pyta, czy to oznacza, że automatyzacja jest zawodnym rozwiązaniem, odpowiedź brzmi: nie, oznacza to, że automatyzacja bez monitoringu jest niekompletnym wdrożeniem. To różnica fundamentalna, nie kosmetyczna.

Checklista monitoringu, którą wdrażamy domyślnie

Nie traktujemy monitoringu jako opcji premium, którą można dokupić później. Dla nas to część wdrożenia, tak samo jak sam scenariusz. Poniżej konkretne elementy, które wchodzą w skład tej checklisty u klientów Ententry.

• Error workflow na poziomie każdego krytycznego scenariusza. Jeśli workflow się wywali, osobny, prosty scenariusz wysyła powiadomienie na Slacka, maila albo do systemu ticketowego, z informacją: który workflow, który węzeł, jaki błąd.
• Health-check uruchamiany cyklicznie. Krótki scenariusz, który co godzinę albo raz dziennie sprawdza, czy krytyczne integracje (token, połączenie z API, dostęp do arkusza) w ogóle odpowiadają, zanim pojawi się realny ruch danych.
• Centralny log błędów. Wszystkie błędy z różnych scenariuszy trafiają w jedno miejsce, żeby nie trzeba było przeglądać historii wykonań w kilkunastu osobnych workflow, żeby zobaczyć, że coś nie działa.
• Monitoring limitu operacji w planie. Prosty alert, który ostrzega, gdy wykorzystanie planu przekracza np. 80%, zanim scenariusze zaczną się nie wykonywać w połowie miesiąca.
• Przegląd integracji co kwartał. Nie czekamy, aż coś się zepsuje, raz na jakiś czas sprawdzamy, czy dostawca nie ogłosił zmian w API, czy token nadal jest aktualny, czy struktura danych się nie zmieniła.

To nie jest lista aspiracyjna. To konkretne elementy, które wdrażamy od razu, bo koszt dodania error workflow na etapie budowy scenariusza to kilkadziesiąt minut pracy, a koszt jego braku to tydzień ciszy, w którym klient końcowy sam odkrywa awarię.

Jak to wygląda w praktyce, nie w teorii

Weźmy typowy przypadek: firma handlowa, która automatyzuje wystawianie faktur na podstawie zamówień z platformy e-commerce i synchronizację z systemem księgowym. Scenariusz działa świetnie przez pierwsze miesiące. Potem platforma, z której pobierane są zamówienia, zmienia format pola z datą dostawy, dodając do niego strefę czasową. Workflow, który dotąd parsował tę datę po prostu jako tekst, zaczyna rzucać błędem przy każdym nowym zamówieniu z tym polem. Bez error workflow ten błąd leży w historii wykonań n8n, niewidoczny dla nikogo, a faktury po prostu nie są wystawiane. Z error workflow zespół księgowości dostaje wiadomość tego samego dnia, z konkretnym wskazaniem, który węzeł padł i jaki jest komunikat błędu. Naprawa trwa pół godziny, nie tydzień.

Podobnie wygląda to w biurach rachunkowych, gdzie automatyzacja odpowiada za pobieranie dokumentów z banku czy systemu klienta, albo w obsłudze zamówień, gdzie workflow łączy się z wieloma platformami jednocześnie. Im więcej integracji, tym większa szansa, że jedna z nich w danym miesiącu zmieni coś po swojej stronie. To nie jest argument przeciwko automatyzacji, to argument za tym, żeby monitoring był częścią projektu od pierwszego dnia, nie dopisywany po pierwszej wpadce.

Jeśli temat dotyczy akurat procesu fakturowania, warto zobaczyć, jak podchodzimy do tego punktowo: automatyzacja faktur opisuje, które elementy tego procesu najczęściej się psują i jak je zabezpieczamy. Przy integracjach z platformami sprzedażowymi i marketplace'ami podobny wzorzec awarii dotyczy też automatyzacji e-commerce, gdzie zmiany w API Allegro czy kuriera bywają równie częstym źródłem cichych wysypów scenariusza.

Czego monitoring nie naprawi, i gdzie zostaje człowiek

Trzeba powiedzieć wprost, czego taka checklista nie robi. Error workflow i health-check informują o problemie, nie naprawiają go automatycznie. Jeśli dostawca API zmienił strukturę odpowiedzi w sposób, który wymaga przebudowy węzła, potrzebny jest ktoś, kto to zrobi, nie sam system. Monitoring daje czas reakcji liczony w minutach albo godzinach, zamiast w dniach, ale decyzję, co z tym zrobić, i tak podejmuje człowiek.

Drugie ograniczenie: monitoring kosztuje. Trzeba poświęcić czas na budowę error workflow dla każdego krytycznego scenariusza, trzeba kogoś wyznaczyć, kto odbiera alerty i reaguje, trzeba zaplanować kwartalny przegląd integracji. Dla scenariusza, który raz w tygodniu przesyła prosty raport i nie dotyka żadnych pieniędzy czy danych klienta, pełna checklista bywa przesadą. Ocena, które workflow są krytyczne i zasługują na pełny monitoring, a które mogą działać bez niego, to też decyzja, którą warto podjąć świadomie, nie automatycznie stosować maksimum wszędzie.