n8n'de Hata İşleme: Error Workflow'lar ve Hata Bildirimleri

Error workflow, n8n'de workflow ayarlarında "Error workflow" alanında tanımladığınız ve başka bir workflow'un çalıştırması başarısız olur olmaz otomatik olarak başlayan tamamen normal bir otomasyondur. Error Trigger düğümü, tek tek düğümlerin Retry On Fail ayarları ve e-posta veya Microsoft Teams üzerinden bir bildirimle birleştirildiğinde, hataların fark edilmeden geçmemesi, bunun yerine otomatik olarak tekrarlanması veya ilgili ekibe bildirilmesi sağlanabilir. Güncelleme: Temmuz 2026.

Error workflow nedir ve ne zaman devreye girer?

n8n dokümantasyonuna göre bir error workflow, başka bir otomasyon için "Workflow Settings" içinde tanımladığınız ve o otomasyonun çalıştırması başarısız olur olmaz çalıştırılan ayrı bir workflow'dur. Dokümantasyona göre tipik bir kullanım senaryosu, bir hata durumunda "e-posta veya Slack bildirimleri" göndermektir. Tek bir error workflow, birden fazla üretim workflow'u için yeniden kullanılabilir, böylece her otomasyon için ayrı bir hata işleme oluşturmanız gerekmez. Önemli olan, bir error workflow'un manuel çalıştırılarak test edilememesidir: dokümantasyona göre Error Trigger yalnızca başka bir workflow'un otomatik çalıştırması gerçekten başarısız olduğunda tepki verir. Daha fazla ayrıntı için bkz: n8n'in hata işleme dokümantasyonu.

Bir error workflow nasıl kurulur?

Önce yalnızca hata durumu için var olan bağımsız bir workflow oluşturursunuz, ardından bunu izlenecek workflow ile bağlarsınız.

• Hata işleyici workflow'unu oluşturun: Error Trigger'ı ilk düğüm olarak içeren yeni bir workflow oluşturun, ona "Error Handler" gibi bir ad verin ve kaydedin.
• Hedef workflow'u açın: Hatalarını izlemek istediğiniz workflow'u açın ve orada Options, ardından Settings bölümüne gidin.
• Error workflow'u atayın: "Error workflow" alanında daha önce oluşturduğunuz hata işleyici workflow'u seçin ve ayarı kaydedin.

Yalnızca Error Trigger üzerinden başlatılan bir workflow'un, error workflow olarak çalışması için ayrıca yayınlanması gerekmez.

Error Trigger bir hata durumunda hangi bilgileri sağlar?

Error Trigger, başarısız olan çalıştırmayla ilgili yapılandırılmış veriler aktarır ve bunlardan anlamlı bir bildirim oluşturulabilir. Error Trigger düğümü dokümantasyonuna göre bu veriler arasında şunlar bulunur:

• execution.id ve execution.url: başarısız olan çalıştırmanın kimliği ve bağlantısı, ancak hata zaten ana otomasyonun tetikleyici düğümünde oluşuyorsa bunlar eksiktir.
• execution.error: yığın izlemesi (stack trace) dahil olmak üzere asıl hata mesajı.
• execution.lastNodeExecuted: çalıştırmanın başarısız olduğu düğüm.
• execution.retryOf: yalnızca başarısız olan çalıştırma kendisi zaten bir tekrar denemesiyse mevcuttur.
• workflow.id ve workflow.name: hangi workflow'un etkilendiği.

Ayrıca Stop And Error düğümü ile bilinçli olarak bir hata zorlanabilir, örneğin teknik olarak bir düğüm hatası olmasa bile, tutarsız bir veri durumunda error workflow'u kasıtlı olarak tetiklemek için.

Başarısız olan bir çağrı Retry ile otomatik olarak nasıl tekrarlanabilir?

Bir çalıştırma nihai olarak başarısız sayılıp error workflow'a düşmeden önce, her bir düğüm başarısız bir çağrıyı önce otomatik olarak birkaç kez tekrarlayacak şekilde yapılandırılabilir. Bunun için ilgili düğümü açın, ayarlara geçin ve orada "Retry On Fail" seçeneğini etkinleştirin. "Max Tries" ile n8n'in denemeyi kaç kez tekrarlayacağını, "Wait Between Tries (ms)" ile denemeler arasındaki bekleme süresini milisaniye cinsinden belirlersiniz. Her iki değer de API hız sınırlarıyla (rate limits) başa çıkma dokümantasyonuna göre sınırlıdır: Max Tries en fazla 5, Wait Between Tries en fazla 5000 milisaniye. Özellikle hız sınırı olan hizmetlerde dokümantasyon, bir sonraki denemenin tekrar reddedilmemesi için bekleme süresinin ilgili API'nin hız sınırı aralığının üzerinde belirlenmesini önerir.

Ekibinizi e-posta veya Microsoft Teams ile nasıl bilgilendirirsiniz?

Error Trigger'dan sonra, error workflow'a bildirimin gönderileceği düğümü eklemeniz yeterlidir. E-posta bildirimleri için, SMTP kimlik bilgileri bağlantısı gerektiren ve mesajları metin, HTML veya her iki biçimde gönderebilen Send Email düğümü uygundur. Bir Teams kanalına bildirim için, kayıtlı Microsoft kimlik bilgileri aracılığıyla bir kanala mesaj gönderen Microsoft Teams düğümü kullanılabilir. Her iki durumda da mesaj metnini, Error Trigger tarafından sağlanan alanlardan, örneğin workflow adından, execution.error içindeki hata mesajından ve execution.url üzerinden çalıştırmaya giden bağlantıdan oluşturursunuz, böylece alıcılar hangi sürecin etkilendiğini ve ayrıntıları nerede görebileceklerini hemen anlar. Mevcut bir n8n ortamını error workflow'lar, Retry stratejileri ve bildirimlerle teknik açıdan sağlam bir şekilde güvence altına almak isteyenler için bkz: NordFlux'un n8n hizmetleri.

n8n'de hata işleme hakkında sık sorulan sorular

Her workflow için ayrı bir error workflow'a ihtiyacım var mı?

Hayır, tek bir error workflow, birden fazla workflow'un ayarlarında ortak bir error workflow olarak tanımlanabilir. Böylece birçok üretim workflow'u için genellikle merkezi bir bildirim otomasyonu yeterli olur. Özellikle kritik süreçler için yine de kendi eskalasyon mantığına sahip özel bir error workflow oluşturabilirsiniz.

Bir error workflow'u manuel olarak test edebilir miyim?

Hayır, n8n dokümantasyonuna göre bir error workflow manuel çalıştırılarak test edilemez, çünkü Error Trigger yalnızca başka bir workflow'un otomatik çalıştırması gerçekten başarısız olduğunda tepki verir. Bu davranışı yine de kontrol etmek için, bir test workflow'unda Stop And Error düğümünü kullanarak bilinçli olarak bir hata zorlayabilir ve böylece bağlı error workflow'u tetikleyebilirsiniz.

Retry On Fail ile error workflow arasındaki fark nedir?

Retry On Fail, aynı çalıştırma içinde tek bir düğümün çağrısını otomatik olarak tekrarlar, error workflow ise tüm çalıştırma tüm tekrar denemelerine rağmen nihai olarak başarısız olduğunda devreye girer. Her iki mekanizma da birbirini anlamlı şekilde tamamlar: retry'ler, aşılan hız sınırları gibi kısa süreli aksaklıkları giderir, error workflow ise ardından insanları nihai arızalar hakkında bilgilendirir.

Hata işleyici workflow'un etkinleştirilmiş veya yayınlanmış olması gerekir mi?

Hayır, yalnızca Error Trigger üzerinden başlatılan bir workflow'un, dokümantasyona göre çalışması için ayrıca yayınlanması gerekmez. Başka bir workflow, kendi ayarlarında onu bir error workflow olarak referans aldığında ve kendisi başarısız olduğunda otomatik olarak çağrılır.