Error workflow'lar, Retry On Fail ve Teams bildirimleri: n8n'de güvenilir hata işleme nasıl kurulur.
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.
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.
Ö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.
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, 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:
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.
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.
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.
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.
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, 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.
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.
NordFlux'un kurucusu. Webden ve SEO'dan grup ölçeğindeki otomasyona kadar yedi yıllık deneyim, bugün KOBİ'ler için pragmatik biçimde ve Alman veri egemenliğiyle.
Sertifikalar
n8n workflow'larını Wait düğümü, Batching, Retry on Fail ve pagination ile 429 hatalarına karşı nasıl dayanıklı hale getirirsin.
n8n şifreleme anahtarını kaybederseniz, kayıtlı tüm kimlik bilgileri kullanılamaz hale gelir. İş akışlarını, kimlik bilgilerini ve anahtarları doğru şekilde nasıl yedekleyeceğiniz burada.
n8n'de Pin Data, Mock Data ve Debug modu: workflow'ları üretim sistemlerine karşı canlı olarak değil, sabitlenmiş test verileriyle nasıl test edersin.
Gerçekten güvenilir şekilde devreye giren bir error workflow, gerçek hatalarla geçici arızaları ayırt eden retry mantığı ve doğru kişilere ulaşan bildirimler, isteğe bağlı bir ek değil, profesyonel işletimin parçasıdır. NordFlux, hata yönetimi, izleme ve eskalasyon yolları dahil olmak üzere n8n için yönetilen işletim hizmeti sunar; böylece başarısız bir workflow, müşteri fark edene kadar sessiz kalmaz. İlk görüşmede workflow'larınızın hata durumunda bugün nerede sessiz kaldığını inceleriz.
