Hata Yönetimi, Retry ve Loglama
Üretime alınan workflow'lar için sağlam hata yönetimi: Error Trigger, retry stratejileri, alert ve loglama.
Bu bölümde
Test ortamında çalışan bir workflow ile üretimde 7/24 güvenle çalışan workflow arasındaki fark, hata yönetimidir. Gerçek dünyada API'ler bazen 500 döner, ağ kopar, OpenAI rate-limit verir, webhook kaynağı 1 saniyelik gecikmeyle veri gönderir. Sağlam bir workflow bu durumlarda susmaz, çakılmaz; yeniden dener, alternatif yola sapar veya en azından sizi haberdar eder. Bu bölümde n8n'in dört temel mekanizmasını öğreneceksiniz: node seviyesinde Retry On Fail ve Continue On Fail, workflow seviyesinde On Error ayarı, merkezi Error Trigger workflow'u ve gözlemlenebilirlik için audit log + alert akışı.
Konular
- Try / On Error workflow ayarı
- Error Trigger ile merkezi hata yakalama
- Retry On Fail: gecikme ve maksimum deneme
- Continue On Fail: kısmi başarıya izin vermek
- Alert akışı: Slack/Telegram'a hata bildirimi
- Loglama ve audit trail saklama
Üç katmanlı savunma: Node, Workflow, Hesap
n8n'de hatayı üç ayrı yerde yakalayabilirsiniz. (1) Node seviyesi: 'Retry On Fail' ile aynı node 3-5 kez tekrar dener; 'Continue On Fail' ile node patlasa bile sonraki adıma geçilir. (2) Workflow seviyesi: workflow ayarlarında 'Error Workflow' alanına bir hata workflow'u seçersiniz — herhangi bir node patlarsa o workflow tetiklenir. (3) Hesap seviyesi: tüm workflow'larda varsayılan error workflow tanımlayabilirsiniz. Doğru strateji: kritik node'larda Retry, dış servisle konuşan node'larda Continue + IF dallanması, her workflow'da bir Error Workflow ataması.
Retry On Fail: doğru parametreleri seçmek
Her node'un ayarlarında 'Settings → Retry On Fail' bulunur. Burada üç değer önemlidir. Max Tries (3-5): kaç kez denesin. Wait Between Tries (ms): denemeler arası bekleme — sabit değer (1000ms) yerine 'exponential backoff' düşünün: 1s, 2s, 4s, 8s. n8n'in dahili wait sabittir ama bir Wait node'u + Code node'la kendi backoff'unuzu yazabilirsiniz. Hangi hatalarda denesin: tüm hatalar değil, sadece transient olanlar (429 rate limit, 502/503/504 ağ, timeout). 400/401/404 gibi kalıcı hatalarda tekrar denemek anlamsızdır — IF'le ayırın ve Error Trigger'a yönlendirin.
Continue On Fail: kısmi başarıya izin vermek
100 satırlık bir Loop'ta 73'üncü satır patlarsa tüm workflow durmasın. 'Continue On Fail' bunu sağlar: hata olsa da akış sonraki item ile devam eder. Önemli incelik: 'Continue' açıldığında o node'un output'u { error: "..." } şeklinde gelir — bir sonraki adımda IF ile 'item.error var mı?' diye dallanmazsanız hatalı kayıt da başarılı gibi işlenir. Pratik kalıp: HTTP Request (Continue On Fail) → IF ($json.error ? error-branch : success-branch) → başarılılar DB'ye, başarısızlar 'failed_records' tablosuna gider.
Error Trigger: merkezi hata workflow'u
n8n'in en güçlü hata mekanizması Error Trigger node'udur. Yeni bir workflow oluşturun, ilk node olarak 'Error Trigger' koyun, kaydedin. Sonra başka workflow'ların ayarlarından 'Error Workflow' olarak bu yenisini seçin. Artık o workflow'ların herhangi bir node'u patlarsa Error Trigger tetiklenir ve size şu bilgileri verir: execution.id, execution.url (Editor'da hatayı görmek için direkt link), workflow.name, node.name, hata mesajı, timestamp. Tek bir error workflow'u tüm workflow'lara bağlayarak hatayı tek yerde toplamış olursunuz.
Alert akışı: hangi kanala, ne zaman, ne kadar?
Hata bildirimini hangi kanala göndereceğinize hatanın severity'sine göre karar verin. Düşük (örn. tek bir webhook 4xx): sadece logla, kimseyi uyarma. Orta (1 saatte 5+ hata): Slack/Telegram'a özet bildirim. Yüksek (DB bağlantısı koptu, AI Agent tamamen çalışmıyor): doğrudan telefon — PagerDuty veya Telegram'a sesli arama. Alert spam'ini önlemek için: aynı hatayı 5 dakika içinde bir kez bildir (dedup için hata hash'i + Set + Redis/Postgres'de TTL). Mesaja mutlaka şunları koyun: workflow adı + node adı + Editor link (n8n.example.com/workflow/execution/<id>) + zaman + örnek hata mesajı. Boş 'workflow failed' mesajı kimseye yardım etmez.
Loglama ve audit trail: neyi nereye yazmalı?
n8n'in kendi Executions ekranı son 30 gün için yeterlidir ama uzun vadeli audit için yetersizdir. Pratik çözüm: kritik workflow'ların başına ve sonuna bir Postgres/MongoDB Insert ekleyin → { workflow, execution_id, started_at, ended_at, status, input_hash, output_summary } yazın. Hata workflow'unuz da aynı tabloya 'failed' kaydı atsın. Bu sayede 'son 24 saatte hangi workflow kaç kez çalıştı, kaç başarısız' sorgusunu tek SQL'le çekersiniz. PII içerebilecek input'ları log'a yazarken alan adı + hash kaydedin, ham veriyi değil. Compliance gerekiyorsa input/output'u şifreli S3'e koyup tabloda referans tutun.
Dead Letter Queue pattern'i
Bazı hatalar sonradan elle düzeltilebilir (örn. CRM geçici çalışmadı, kullanıcı sonradan elle gönderilmek istenir). Bunlar için 'Dead Letter Queue' (DLQ) tablosu kurun: 'failed_jobs' adında bir Postgres tablosu — workflow_name, payload (JSON), error_message, retry_count, next_retry_at, status. Hata Error Trigger'a düştüğünde bu tabloya yazın. Ayrı bir Schedule Trigger workflow'u her 10 dakikada bir 'next_retry_at' geçmiş ve retry_count<5 olan satırları çekip yeniden denesin, başarısızlıkta retry_count++. Bu pattern n8n'i mesaj kuyruğu olmadan dirençli hale getirir.
Üretim öncesi checklist: workflow'unuz hazır mı?
Bir workflow'u 'production' yapmadan önce şu 8 maddeyi doğrulayın. (1) Tüm dış API çağrılarında Retry On Fail aktif mi? (2) Hangi hatalarda retry, hangilerinde IF dallanması var mı? (3) Workflow'un Settings'inde Error Workflow atandı mı? (4) Error Workflow'u, kanal + execution URL + workflow + node bilgisini iletiyor mu? (5) Loop'larda Continue On Fail + failed-records tablosu var mı? (6) Webhook'larda timeout ve maksimum payload limiti tanımlı mı? (7) Credentials gerçekten 'production' credentialleri mi (test API key değil)? (8) Executions retention süresi (örn. 30 gün) ve audit log saklama süresi mevzuat gereksinimini karşılıyor mu? Bu listeyi her workflow için bir kez geçtikten sonra 'Active' yapın.
Bu bölümün workflow'u (n8n editör görünümü)