Jak sprawdzić dokładny log błędu 500 w n8n?

W panelu n8n przejdź do zakładki Executions w lewym menu. Znajdź nieudane wykonanie oznaczone na czerwono (Error) i kliknij w nie — zobaczysz dokładnie, który węzeł rzucił wyjątek wraz ze stack trace.

Czy n8n w kontenerze Docker wymaga specjalnych uprawnień dla webhooków?

Nie, ale jeśli n8n działa za reverse proxy (Nginx, Traefik), upewnij się, że zmienna WEBHOOK_URL w pliku .env wskazuje pełny publiczny adres z HTTPS, np. https://n8n.twojadomena.pl/.

Jak zapobiec ponownemu wysyłaniu tych samych webhooków (duplikatom)?

Wdróż mechanizm idempotencji: przed przetworzeniem zdarzenia sprawdź w bazie SQLite/MySQL, czy identyfikator zdarzenia (np. transaction_id lub event_id) był już wcześniej zapisany.

Błąd 500 w webhooku n8n — przyczyny i konfiguracja error handling

Błąd 500 (Internal Server Error) w węźle Webhook n8n wynika zazwyczaj z przekroczenia limitu czasu oczekiwania na odpowiedź (Response Timeout), nieobsłużonego wyjątku w dalszych węzłach przy trybie „When Last Node Finishes” lub błędu parsowania zbyt dużego payloadu JSON. Najskuteczniejszym rozwiązaniem jest przełączenie trybu odpowiedzi na „Immediately” lub skonfigurowanie dedykowanego Error Trigger Workflow.

Dlaczego webhook n8n zwraca kod HTTP 500?

Domyślna konfiguracja węzła Webhook w n8n zakłada, że serwer odbierający żądanie czeka na przetworzenie całego scenariusza przed odesłaniem odpowiedzi HTTP do nadawcy. Jeśli dowolny węzeł w łańcuchu (np. zapytanie do bazy MySQL, webhook WooCommerce czy odpytanie modelu AI) rzuci nieobsłużony błąd lub przekroczy limit czasu (timeout), n8n automatycznie zwraca nadawcy kod HTTP 500.

Dla systemów e-commerce (np. bramek płatności lub webhooków zamówień WooCommerce) kod 500 oznacza niepowodzenie transakcji i wywołuje niekontrolowane ponowienia (retry storm), które potrafią zablokować bazę danych sklepu.

4 najczęstsze przyczyny błędu 500 w n8n Webhook

1. Tryb „When Last Node Finishes” zamiast odpowiedzi asynchronicznej

Jeśli webhook czeka na zakończenie całego przepływu, a przepływ trwa dłużej niż 30–60 sekund, reverse proxy (Nginx, Traefik lub Cloudflare) przed n8n zerwie połączenie i zwróci 504 Gateway Timeout lub 500 Internal Error.

Naprawa: W konfiguracji węzła Webhook zmień parametr Response Mode z When Last Node Finishes na Immediately. n8n natychmiast zwróci nadawcy kod HTTP 200 z potwierdzeniem odbioru, a ciężkie przetwarzanie wykona asynchronicznie w tle.

2. Przekroczony limit wielkości payloadu (N8N_PAYLOAD_SIZE_MAX)

Domyślny limit wielkości żądania w n8n wynosi 16 MB. Przy przesyłaniu dużych faktur PDF, skanów base64 lub hurtowych partii zamówień, n8n odrzuca żądanie błędem 500/413.

Naprawa: W pliku środowiskowym .env Twojego kontenera n8n (Docker) zwiększ limit:

N8N_PAYLOAD_SIZE_MAX=64
EXECUTIONS_DATA_MAX_SIZE=64

3. Brak globalnego przepływu obsługi błędów (Error Trigger)

Gdy węzeł zewnętrzny rzuca błąd, wykonanie scenariusza zostaje przerwane. W n8n możesz stworzyć dedykowany Error Workflow, który przechwyci każdy błąd:

Stwórz nowy scenariusz i dodaj węzeł Error Trigger.
Dodaj wysyłkę alertu na Slack, e-mail lub Telegram z ID wykonania i komunikatem błędu.
W ustawieniach głównego scenariusza (Workflow Settings) w polu Error Workflow wskaż utworzony scenariusz.

4. Błędny format odpowiedzi JSON w węźle „Respond to Webhook”

Jeśli używasz dedykowanego węzła Respond to Webhook, ale przekazujesz do niego dane niebędące poprawnym obiektem JSON lub ciągiem tekstowym, n8n zakończy żądanie błędem 500.

// Prawidłowa struktura zwracana w węźle Code przed Respond to Webhook:
return {
  status: "success",
  received_at: new Date().toISOString(),
  order_id: $json.id
};

Podsumowanie inżynierskie

Produkcyjne webhooki w architekturze Zero-SaaS muszą działać asynchronicznie. Potwierdź odbiór danych w 50 ms (kod 200), a logikę i integracje z bazą wykonaj w kolejce zadań. W ten sposób żaden zewnętrzny timeout nie zakłóci pracy Twojego sklepu.