Zbudowałeś workflow. Przetestowałeś. Działa. Aktywowałeś i poszedłeś spać. O 3:00 w nocy API zwróciło 429 (rate limit). Workflow padł. Nikt nie wiedział do rana. 47 leadów przepadło.
To nie jest teoretyczny scenariusz. To się dzieje codziennie. Ten artykuł pokazuje jak tego uniknąć.
TL;DR
- Error Workflow – globalny „łapacz" błędów, wysyła alert gdy cokolwiek padnie
- Retry on Fail – automatyczne ponawianie (wbudowane w każdy node)
- Try/Catch – wzorzec dla krytycznych operacji (Continue on Fail + IF)
- Monitoring – Executions log + alerty + dashboardy
- Zasada: Każdy produkcyjny workflow potrzebuje error handling. Bez wyjątków.
Nie masz jeszcze n8n? Zainstaluj w 15 minut. Szukasz szerszego kontekstu? Kompletny poradnik n8n.
Dlaczego workflow padają
Workflow nie padają bo je źle zbudowałeś. Padają bo świat jest nieprzewidywalny:
- API timeout – zewnętrzny serwis nie odpowiada (503, 504)
- Rate limiting – za dużo requestów (429)
- Zmiana API – endpoint zmienił strukturę odpowiedzi
- Brak danych – pole
emailjestnullbo ktoś nie wypełnił formularza - Credentials wygasły – token OAuth expired po 90 dniach
- Serwer n8n – brak pamięci, restart, aktualizacja
Każdy z tych scenariuszy jest kwestią czasu, nie „czy".
Error Workflow – Twoja pierwsza linia obrony
Error Workflow to specjalny workflow, który uruchamia się gdy inny workflow padnie. Jeden Error Workflow obsługuje wszystkie Twoje workflow.
Jak skonfigurować
Krok 1: Stwórz Error Workflow
- Utwórz nowy workflow → nazwij „Error Handler"
- Dodaj node Error Trigger (to jedyny trigger w tym workflow)
- Error Trigger automatycznie otrzymuje dane o błędzie:
- Nazwa workflow, który padł
- Nazwa node'a, który rzucił błąd
- Treść błędu
- Timestamp
- Execution ID
Krok 2: Dodaj powiadomienie
Podłącz do Error Trigger node powiadomienia:
Error Trigger → Slack/Email/SMS
Slack message template:
Workflow padł!
Workflow: {{ $json.workflow.name }}
Node: {{ $json.execution.lastNodeExecuted }}
Błąd: {{ $json.execution.error.message }}
Czas: {{ $now.format('dd.MM.yyyy HH:mm') }}
Link: {{ $json.execution.url }}
Krok 3: Podłącz do workflow
W każdym produkcyjnym workflow:
- Otwórz Settings (ikona zębatki)
- W polu Error Workflow wybierz „Error Handler"
- Zapisz
Gotowe. Gdy workflow padnie – dostaniesz alert na Slacku z linkiem do execution.
Error Workflow musi być aktywny (przełącznik Active ON). Nieaktywny Error Workflow = brak alertów = fałszywe poczucie bezpieczeństwa.
Retry on Fail – automatyczne ponawianie
Większość błędów jest tymczasowa. API nie odpowiada przez 2 sekundy, ale po 10 sekundach działa. Retry rozwiązuje to automatycznie.
Jak włączyć
Każdy node w n8n ma wbudowany retry:
- Otwórz node → Settings (zakładka)
- Włącz Retry on Fail
- Ustaw:
- Max Tries: 3 (ile prób)
- Wait Between Tries: 1000 ms (ile czekać)
- Backoff: Linear lub Exponential
Kiedy jakiej strategii
| Strategia | Opis | Kiedy |
|---|---|---|
| Linear | Stały odstęp (np. 1s, 1s, 1s) | Krótkie przerwy serwisu |
| Exponential | Rosnący odstęp (1s, 2s, 4s, 8s) | Rate limiting, przeciążony API |
Złota reguła retry: 3 próby z exponential backoff (1s → 2s → 4s). Rozwiązuje 90% tymczasowych błędów. Więcej prób rzadko pomaga – po 3 próbach problem jest raczej trwały.
Kiedy NIE retryować
- 400 Bad Request – dane są złe, retry nic nie zmieni
- 401 Unauthorized – credentials wygasły, trzeba odnowić
- 404 Not Found – zasób nie istnieje
- Logika biznesowa – duplikat w CRM, brak stocku
Retry ma sens tylko dla błędów tymczasowych (5xx, timeout, rate limit).
Try/Catch – kontrola przepływu przy błędach
Czasami chcesz obsłużyć błąd zamiast zatrzymać workflow. Na przykład: jeden email z 50 nie wysłał się – nie chcesz zabijać całego batcha.
Wzorzec: Continue on Fail
- Na krytycznym node włącz Settings → Continue on Fail
- Node nie zatrzymuje workflow przy błędzie – zamiast tego przekazuje dane z informacją o błędzie
- Dodaj node IF po nim:
- Warunek:
{{ $json.error }}is not empty - True (błąd) → logowanie + alert
- False (sukces) → normalne przetwarzanie
- Warunek:
HTTP Request [Continue on Fail: ON]
→ IF (error exists?)
→ True: Log error + Slack alert
→ False: Normalne przetwarzanie
Kiedy Continue on Fail
- Batch processing (50 emaili, 100 rekordów)
- Operacje na wielu źródłach (jedno może być niedostępne)
- Non-critical operations (logowanie, analytics)
Kiedy NIE
- Płatności (nie chcesz „kontynuować" po nieudanej płatności)
- Operacje z side effects (jeśli krok 1 się udał ale krok 2 padł – trzeba cofnąć krok 1)
Wzorce error handling na produkcji
Wzorzec 1: Alert + Log
Najprostszy – wystarczy na 80% przypadków.
[Twój workflow]
→ Error Workflow → Slack alert + Google Sheets log
Google Sheets log z kolumnami:
timestamp,workflow_name,node_name,error_message,execution_url,status(open/resolved)
Masz historię błędów, możesz analizować wzorce.
Wzorzec 2: Retry + Fallback
Dla workflow z jednym krytycznym API call.
HTTP Request [Retry: 3x exponential]
→ IF (success?)
→ True: Normalny flow
→ False: Fallback (np. kolejka, manual review)
Fallback to plan B – np. zamiast automatycznej odpowiedzi, stwórz task w Asanie do ręcznej obsługi.
Wzorzec 3: Dead Letter Queue
Dla workflow przetwarzających dużo danych (100+ itemów).
Batch processing → Sukces: Normalne przetwarzanie
→ Błąd: Google Sheets "Dead Letter Queue"
→ Schedule: Codziennie retry z DLQ
Itemye, które padły, trafiają do „kolejki martwych wiadomości". Osobny workflow codziennie próbuje je przetworzyć ponownie.
Wzorzec 4: Circuit Breaker
Dla workflow zależnych od niestabilnego API.
HTTP Request → Sukces: normalny flow
→ 3x Błąd pod rząd: wyłącz workflow + alert "API down"
Zamiast bombardować niestabilne API retry'ami (co pogarsza sytuację), workflow się wyłącza i czeka na interwencję.
Monitoring i debugging
Executions log
n8n zapisuje każde uruchomienie workflow w Executions:
- Status: Success / Error / Running
- Czas trwania
- Dane – co wchodziło i wychodziło z każdego node'a (klikalne)
- Błędy – stack trace z dokładną lokalizacją
Wejdź: Menu → Executions lub w workflow → Executions (ikona zegara).
Self-hosted: domyślnie n8n trzyma executions bez limitu (to zajmuje dysk!). Ustaw EXECUTIONS_DATA_MAX_AGE=168 (7 dni) w zmiennych środowiskowych. Cloud: retencja zależy od planu.
Debugging krok po kroku
Gdy workflow padł:
- Otwórz Executions → znajdź failed execution
- Kliknij – zobaczysz workflow z zaznaczonym node'em, który padł
- Kliknij node → zobacz Input (dane wejściowe) i Error (treść błędu)
- Najczęściej problem jest w danych (brakujące pole, zły format) lub credentials (expired token)
Proaktywny monitoring
Nie czekaj na błędy – monitoruj metryki:
Workflow „Health Check" (co godzinę):
Schedule Trigger → HTTP Request (GET n8n-api/health)
→ IF (status ≠ ok)
→ Slack alert
Execution stats (co dziennie):
Schedule Trigger → n8n API (GET /executions?status=error&lastNDays=1)
→ IF (count > 0)
→ Slack: "Wczoraj X workflow padło"
Checklist: Error Handling na produkcji
Zanim włączysz workflow na produkcji – przejdź tę checklistę:
- Error Workflow podłączony i aktywny
- Retry on Fail na node'ach z zewnętrznym API (3x, exponential)
- Continue on Fail na non-critical operations
- Credentials – sprawdzone, z notką kiedy wygasają
- Monitoring – wiesz jak sprawdzić Executions log
- Alert – dostajesz powiadomienie gdy workflow padnie (Slack/email/SMS)
- Timeout – workflow ma sensowny timeout (nie wisi w nieskończoność)
- Testy – przetestowałeś scenariusze: poprawne dane, brak danych, błędne dane, API timeout
Najczęstsze błędy i rozwiązania
| Błąd | Przyczyna | Rozwiązanie |
|---|---|---|
ECONNREFUSED | API nie odpowiada | Retry + fallback |
429 Too Many Requests | Rate limit | Exponential backoff + zmniejsz batch |
401 Unauthorized | Token wygasł | Odnów credentials, ustaw reminder |
TypeError: Cannot read property | Brakujące pole w danych | Dodaj walidację (IF: field exists) |
ETIMEDOUT | Timeout połączenia | Zwiększ timeout w node, retry |
Execution was stopped | Ręczne zatrzymanie lub limit | Sprawdź max execution time |
FAQ
Czy każdy workflow potrzebuje error handling?
Workflow testowe i jednorazowe – nie. Każdy workflow na produkcji (aktywny, automatyczny) – tak. Minimum to Error Workflow z alertem.
Ile kosztuje brak error handling?
Zależy od workflow. Lead capture bez error handling = utracone leady. Fakturowanie bez error handling = niewystawione faktury. Obsługa klienta bez error handling = niezadowoleni klienci. Policz sam.
Czy n8n ma wbudowany monitoring?
Tak – Executions log. Ale nie wysyła alertów automatycznie – musisz skonfigurować Error Workflow. n8n Enterprise ma zaawansowany monitoring, self-hosted wymaga własnego setupu.
Jak testować error handling?
Najprościej: w HTTP Request node wpisz URL, który zwraca błąd (np. httpstat.us/500). Sprawdź czy retry działa, czy Error Workflow wysyła alert, czy Continue on Fail poprawnie routuje.