n8n’de gerçekten okunan hata uyarıları

Tek bir ortak hata akışı

Error Trigger düğümüyle başlayan tek bir akış oluşturun ve canlıdaki her akışın ayarlarında bunu hata akışı (error workflow) olarak seçin. Otomatik (production) bir çalışma başarısız olduğunda n8n bu akışı; akışın adı ve kimliği, hata mesajı, en son çalışan düğüm ve çalışmalar kaydediliyorsa başarısız çalışmanın bağlantısıyla çalıştırır. Elle yapılan test çalıştırmaları hata akışını tetiklemez.

Akışın ortak olması, biçimin, kanalın ve kuralların tek bir yerde durmasını sağlar. Her uyarıyı aynı biçimde yazın:

• Ne bozuldu: akışın adı ve hata veren düğüm.
• Neden: kısaltılmış hata mesajı.
• Nereye bakılmalı: çalışmanın bağlantısı.
• Kim ilgilenecek: küçük bir eşleştirme tablosundan alınan, akıştan sorumlu ekip veya rol.

Bir iş kuralı ihlal edildiğinde akışı bilerek durdurmak için Stop and Error düğümünü kullanın; böylece bu durumlar da aynı uyarı yolundan geçer.

Her hatada değil, durum değiştiğinde uyarı

Beş dakikada bir çalışan ve kapalı bir API’ye bağlanan bir akış saatte on iki kez hata verir. Kimsenin on iki mesaja ihtiyacı yoktur. Her akışın son bilinen durumunu (çalışıyor veya hatalı) küçük bir tabloda tutun: n8n’in yeni sürümlerindeki veri tabloları (data tables), bir veritabanı tablosu veya bir hesap tablosu.

1. Hata olduğunda hata akışı durumu okur. Durum “çalışıyor” ise “hatalı” yapar ve uyarı gönderir. Zaten “hatalı” ise yalnızca sayacı artırır.
2. Başarılı çalışmada, akışın son adımı durumu “çalışıyor” olarak yazar. Önceki durum “hatalı” ise ne kadar süre bozuk kaldığıyla birlikte kısa bir “düzeldi” mesajı gönderir.
3. Akış uzun süre hatalı kalırsa her hatayı tekrarlamak yerine önceden belirlenen bir süre sonra tek bir hatırlatma gönderin.

Uyarıdan önce, dış servislere bağlanan düğümlerde Retry On Fail ayarını açın; kısa bir zaman aşımı bildirilmek yerine yeniden denenir.

Boş çalışmaları yakalamak

Bazı hatalar sessizdir: çalışma başarılı görünür ama hiçbir şey işlemez. Bir erişim anahtarının süresi dolmuş ve API boş liste döndürüyordur, bir filtre değişmiştir ya da kaynak veri göndermeyi bırakmıştır. Hata akışı hiç çalışmaz.

Veriyi getiren adımdan sonra kayıtları sayın. Bir düğüm hiç kayıt döndürmezse sonraki düğümler çalışmaz; bu yüzden o düğümde Always Output Data ayarını açın. Bu durumda düğüm tek bir boş kayıt döndürür; kontrolü kayıt sayısına değil, gerçek veri olup olmadığına göre yapın. Normalde boş gelmemesi gereken bir çalışmada (ör. her gün satır gelen bir aktarım) veri yoksa akışı Stop and Error düğümüyle bitirin; çalışma böylece ortak hata akışından ve durum kurallarından geçer.

Neyin “olağandışı boş” sayılacağına her akış için ayrı karar verin. Bazı günler gerçekten boş olabilen kaynaklarda uyarıyı ancak art arda birkaç boş çalışmadan sonra gönderin.

Kaçırılan zamanlanmış çalışmalar

n8n sunucusu kapalıysa, akış devre dışı bırakılmışsa veya zamanlama hiç tetiklenmediyse başarısız bir çalışma da, hata uyarısı da olmaz. Bunu yalnızca bir sinyal bekleyen bir kontrol yakalayabilir.

1. Her zamanlanmış akışın sonunda bir “yaşam sinyali” kaydedin: son başarılı çalışmanın zamanı.
2. Ayrı bir kontrol, her sinyali beklenen aralık ve bir tolerans payıyla karşılaştırır; geciken akış için bir kez uyarı gönderir.
3. Bu kontrolü izlediği n8n sunucusunun dışında çalıştırın; örneğin yaşam sinyali (heartbeat) izleyen bir servis ya da başka bir sunucudaki zamanlanmış görev. Aynı sunucudaki bir kontrol, sunucuyla birlikte durur. Kendi sunucunuzda çalışan n8n’i, sağlık kontrolü uç noktası üzerinden de izleyebilirsiniz.

Uyarıları kim okuyacak?

• Uyarıları kişisel bir posta kutusuna değil, sorumlu ekibin zaten takip ettiği tek bir kanala gönderin.
• Yazılımcı olmayan birinin de anlayacağı sade bir dil kullanın: ne durdu, neyi etkiliyor, nereye bakılmalı.
• Uyarı listesini ayda bir gözden geçirin: kimsenin üzerine bir şey yapmadığı uyarı değiştirilmeli ya da kaldırılmalıdır.

İlgili proje ve hizmet