Naprawa automatyzacji
Scenariusz w n8n albo Make przestał działać: 7 najczęstszych przyczyn
Krótka odpowiedź: najpierw zajrzyj do historii wykonań (Executions w n8n, historia scenariusza w Make) i znajdź pierwsze wykonanie, które zakończyło się błędem. To zazwyczaj najszybszy sposób, żeby ustalić, co się stało. Najczęściej winne jest wygasłe połączenie z kontem, zmieniona nazwa pola lub kolumny, inny układ pliku albo wyczerpany limit operacji. Zdarza się też, że Make sam wyłączył scenariusz po kolejnych błędach.
Wolisz zlecić to komuś? Naprawa automatyzacji n8n, Make, Zapier: robimy to za Ciebie, 490 zł za szybką naprawę.
Kiedy już naprawisz problem, warto od razu ustawić powiadomienia. W n8n służy do tego error workflow z węzłem Error Trigger (n8n Docs). W Make możesz skorzystać z obsługi błędów i niekompletnych wykonań (Make Help). Dzięki temu następnym razem dowiesz się o awarii od razu, a nie dopiero wtedy, gdy ktoś zauważy brakujące dane.
7 przyczyn w tabeli
| # | Przyczyna | Objaw | Gdzie szukać |
|---|---|---|---|
| 1 | Wygasłe połączenie, token albo hasło | błąd autoryzacji, np. 401 | pierwszy krok, który łączy się z usługą |
| 2 | Zmiana nazwy kolumny w arkuszu albo pola w formularzu | puste wartości, zapis w złej kolumnie | krok czytający arkusz albo formularz |
| 3 | Inny układ pliku (CSV, Excel) | błąd parsowania albo przesunięte dane | krok wczytujący plik |
| 4 | Usługa zmieniła API albo pole | nagle pusty wynik albo błąd 4xx | krok wywołujący API |
| 5 | Limit operacji w planie | scenariusz staje pod koniec okresu rozliczeniowego | ustawienia organizacji i planu |
| 6 | Scenariusz wyłączony po błędach | nic się nie dzieje, brak nowych wykonań | status scenariusza |
| 7 | Błąd bez powiadomienia | braki widać po kilku dniach | ustawienia obsługi błędów |
Przyczyny od 1 do 4 znamy z własnych obserwacji przy naprawianiu automatyzacji. Punkty 5 i 6 są opisane w dokumentacji Make. Warto się z nimi zapoznać, bo scenariusz może przestać działać bez żadnej ingerencji użytkownika.
Jak Make wyłącza scenariusz
Nie każdy wie, że Make potrafi sam wyłączyć scenariusz, który regularnie kończy się błędem. Zasady są opisane w pomocy Make:
- Jeśli nie ustawisz obsługi błędów i nie włączysz niekompletnych wykonań, domyślnie działa Rollback. Scenariusz kończy się błędem, a po kilku nieudanych wykonaniach z rzędu Make go wyłącza.
- Domyślny próg to 3 błędy z rzędu.
- Jeśli scenariusz korzysta z natychmiastowego wyzwalacza, np. webhooka, Make wyłącza go już po pierwszym błędzie.
- Niektóre błędy, w tym przekroczenie limitu operacji (OperationsLimitExceededError), limitu rozmiaru danych czy błąd walidacji konta, powodują natychmiastowe wyłączenie harmonogramu.
- Niekompletne wykonania (Store incomplete executions) są domyślnie wyłączone (Make Help). Po włączeniu tej opcji Make zapisuje nieudane wykonania, dzięki czemu można później poprawić problem i je dokończyć.
Dlatego jeśli scenariusz nagle przestał działać i nie widzisz żadnych nowych wykonań, zaczęlibyśmy od sprawdzenia, czy nadal jest włączony. Czasem problemem nie jest sam przepływ danych, tylko to, że Make przestał go uruchamiać.
Jak n8n informuje o błędzie
W n8n można przypisać do każdego workflow osobny error workflow, który uruchomi się, gdy coś pójdzie nie tak. Nie trzeba przy tym budować oddzielnego mechanizmu dla każdej automatyzacji. Jeden error workflow może obsługiwać ich wiele.
Taki workflow musi zaczynać się od węzła Error Trigger. Dalej możesz dodać np. wysłanie maila z informacją o błędzie. Cały mechanizm jest opisany w dokumentacji n8n.
Jest tu jeden szczegół, o którym łatwo zapomnieć. Error Trigger nie uruchamia się podczas ręcznych testów. Działa tylko przy automatycznych wykonaniach (n8n Docs, Error Trigger).
Jeśli więc testujesz scenariusz ręcznie, widzisz błąd, ale nie dostajesz powiadomienia, nie musi to oznaczać, że źle skonfigurowałeś alert. Sprawdź go na rzeczywistym, zaplanowanym wykonaniu.
Kroki naprawy
Kiedy trafia do nas niedziałający scenariusz, zaczynamy od ustalenia, w którym miejscu coś się zepsuło. Nie ma sensu zmieniać ustawień na ślepo, bo łatwo w ten sposób dołożyć kolejne problemy.
- Ustal, od kiedy nie działa. Otwórz historię wykonań i znajdź ostatnie udane oraz pierwsze nieudane wykonanie. To pozwoli zawęzić poszukiwania do konkretnego momentu.
- Przeczytaj komunikat błędu w kroku, który się wysypał. Kod 401 albo 403 zwykle wskazuje na problem z dostępem. Jeśli pojawia się błąd parsowania, sprawdź plik wejściowy.
- Sprawdź, co zmieniło się w tym dniu. Może ktoś zmienił hasło, nazwę kolumny w arkuszu albo szablon pliku? A może skończył się limit w planie? Czasem wystarczy porównać dane sprzed awarii i po niej.
- Napraw przyczynę, nie objaw. Jeśli problem pojawił się po zmianie układu pliku, popraw sposób jego odczytywania. Jednorazowe poprawienie danych niewiele da, jeśli przy następnym pliku błąd wróci.
- Uzupełnij dane z okresu awarii, o ile źródłowy system nadal je przechowuje. Samo uruchomienie scenariusza nie oznacza jeszcze, że wszystkie zaległe rekordy zostały przetworzone.
- Przetestuj od początku do końca na kilku prawdziwych przypadkach. Sprawdź nie tylko, czy scenariusz kończy się bez błędu, ale też czy dane trafiają tam, gdzie powinny, i czy mają prawidłowe wartości.
- Włącz alert. W n8n możesz użyć error workflow, a w Make skonfigurować obsługę błędów. Jeśli scenariusz korzysta z arkuszy, zapisz też, których nazw kolumn nie należy zmieniać.
Po naprawie zawsze warto sprawdzić, czy automatyzacja faktycznie nadrobiła zaległości. Zielony status wykonania nie daje jeszcze pewności, że wszystkie dane są kompletne.
Kiedy oddać to komuś
Jeśli scenariusz zbudował ktoś, kto już się nim nie zajmuje, a w historii uzbierało się sporo błędów, samodzielne szukanie przyczyny może zająć więcej czasu niż naprawa przez kogoś, kto zna te narzędzia.
Naprawiamy pojedyncze scenariusze n8n, Make i Zapier, a także makra i importy danych. Szybka naprawa kosztuje 490 zł i zajmuje od 2 do 3 dni roboczych. Jeśli po sprawdzeniu okaże się, że problem jest większy, przygotujemy nową wycenę. Możesz wtedy zrezygnować bez żadnych kosztów.
Więcej informacji znajdziesz tutaj: Naprawa automatyzacji n8n, Make i Zapier.
Jeśli Twój scenariusz łączy sklep z księgowością, może Cię też zainteresować artykuł Zestawienie sprzedaży z Allegro dla księgowej.
FAQ
Scenariusz w Make ma status wyłączony, choć nikt go nie wyłączał. Dlaczego?
Make może wyłączyć scenariusz automatycznie. Domyślnie dzieje się to po 3 błędach z rzędu. Przy natychmiastowym wyzwalaczu wystarczy jeden błąd. Tak samo przekroczenie limitu operacji może spowodować natychmiastowe wyłączenie (Make Help).
Czy po włączeniu scenariusza Make dokończy zaległe dane?
Tylko jeśli wcześniej miałeś włączone niekompletne wykonania. Ta opcja jest domyślnie wyłączona (Make Help). Jeśli nie była aktywna, zaległe dane trzeba uzupełnić osobno. Samo ponowne włączenie scenariusza ich nie przywróci.
Dlaczego mój error workflow w n8n nie wysłał maila podczas testu?
Najprawdopodobniej dlatego, że uruchomiłeś test ręcznie. Error Trigger działa przy automatycznych wykonaniach, a nie przy ręcznym uruchamianiu workflow (n8n Docs).
A Zapier?
Pierwsze cztery przyczyny z tabeli dotyczą również Zapiera. Nie opisujemy tutaj zasad automatycznego wyłączania Zapów, ponieważ nie sprawdziliśmy ich w aktualnej dokumentacji.
Czy warto naprawiać stary scenariusz?
Jeśli wcześniej oszczędzał Ci czas i nadal wykonuje potrzebną pracę, zazwyczaj warto. Nie widzimy natomiast sensu naprawiania automatyzacji, której nikt już nie potrzebuje. W takiej sytuacji lepiej po prostu ją wyłączyć.
Stan na 26.10.2026. Zasady n8n i Make zmieniają się z wersjami i planami.