Zbudowanie workflowu który działa na demo to godzina. Zbudowanie workflowu który działa niezawodnie w produkcji przez rok — to zupełnie inne zadanie. Ten artykuł opisuje konkretne techniki których używamy w każdym wdrożeniu produkcyjnym.
Dlaczego większość workflowów pada w produkcji
- API zewnętrzne zwraca błąd 500 — workflow zatrzymuje się bez powiadomienia
- Struktura danych zmieniła się w zewnętrznym systemie — węzeł nie potrafi przetworzyć nowego formatu
- Timeout połączenia przy dużych plikach
- Rate limiting — za dużo requestów w krótkim czasie
- Pusty wynik — workflow zakłada że dane zawsze są, a gdy ich nie ma — crash
Error Workflow — pierwsza linia obrony
n8n pozwala zdefiniować osobny workflow który uruchamia się gdy główny workflow rzuci błąd. To Twój globalny handler wyjątków.
Minimalna wersja Error Workflow: odbierz błąd → wyślij Slack webhook z nazwą workflowu, nazwą węzła, komunikatem błędu i linkiem do execucji. W 5 minut wiesz co się zepsuło zanim klient się zorientuje.
Retry logic z exponential backoff
Każdy węzeł HTTP Request w n8n pozwala ustawić liczbę prób i czas między nimi. Dla zewnętrznych API ustaw 3 próby z rosnącym interwałem (1s, 5s, 30s). Większość tymczasowych błędów (502, 503, timeout) rozwiązuje się sama przy ponowieniu.
Dla ważniejszych przepływów: zbuduj własny mechanizm retry używając węzłów Wait i SplitInBatches. Możesz wtedy logować każdą próbę i powiadomić po wyczerpaniu limitu.
Walidacja danych na wejściu
Zanim przetworzysz dane — sprawdź czy mają oczekiwaną strukturę. Użyj węzła IF lub Code do weryfikacji: czy pole email istnieje i jest validne, czy wartość liczbowa nie jest null, czy tablica nie jest pusta.
Błąd na początku workflowu jest tani. Błąd po 10 minutach przetwarzania i połowie zapisanych danych — jest kosztowny.
Idempotentność — co to jest i dlaczego to ważne
Idempotentny workflow można uruchomić wielokrotnie z tymi samymi danymi bez skutków ubocznych. Jeśli webhook zostanie wysłany dwa razy (co zdarza się w realu), Twój workflow nie powinien stworzyć duplikatu w CRM.
Implementacja: zanim stworzysz rekord, sprawdź czy już istnieje (wyszukaj po unikalnym ID). Użyj UPSERT zamiast INSERT tam gdzie to możliwe.
Monitoring i logi
n8n loguje wszystkie execucje — możesz przejrzeć historię, dane wejściowe i wyjściowe każdego węzła. Dla workflowów produkcyjnych dodaj własne logowanie: węzeł HTTP Request wysyłający metryki do prostego arkusza lub do Datadog/Grafany.
Minimalne logi które warto zbierać: timestamp uruchomienia, czy zakończył się sukcesem, liczba przetworzonych rekordów, czas wykonania. Po miesiącu masz dane do optymalizacji i dowody dla klienta że automatyzacja działa.
Zmienne środowiskowe zamiast hardkodowanych wartości
Nigdy nie wstawiaj API keys, URL-i środowisk ani haseł bezpośrednio do węzłów. Używaj credentials n8n dla uwierzytelniania i Variables dla parametrów konfiguracyjnych. Dzięki temu: zmiana środowiska nie wymaga edycji workflowu, secrets nie są widoczne w JSON eksporcie, różne środowiska (dev/prod) to tylko zmiana jednej zmiennej.
Checklista przed deplojem na produkcję
- 1.Error Workflow skonfigurowany i przetestowany
- 2.Retry logic na każdym węźle HTTP
- 3.Walidacja danych na wejściu workflowu
- 4.Logowanie uruchomień i wyników
- 5.Test ze złymi danymi — workflow nie powinien crashować
- 6.Test z pustymi danymi — workflow powinien zakończyć się gracefully
- 7.Wszystkie secrets w credentials, nie w węzłach
- 8.Dokumentacja przepływu jako komentarz lub w Notion
Niezawodność to nie cecha dodawana na końcu. To decyzja architektoniczna podejmowana na początku.