Execution takılı kaldı: Stuck execution'ları bulmak, timeout'ları yapılandırmak

n8n'de bir türlü bitmeyen bir execution görürsün. Workflow çoktan tamamlanmış olması gerekirken durum "Running" veya "Waiting" olarak takılı kalır. Buna asılı kalan ya da "stuck" execution denir ve bu sadece kozmetik bir sorun değildir: varsayılan ayarda, execution değişkenlerine ilişkin resmi referansa göre n8n'in hiçbir zaman sınırı yoktur, EXECUTIONS_TIMEOUT varsayılan olarak -1'dir. Kendi yapılandırman olmadan bir execution teorik olarak sonsuza kadar çalışabilir ve bu sırada kaynakları, worker slotlarını ve queue modunda tüm kuyrukları bloke edebilir.

Bu makale, asılı kalan execution'ları nasıl tanıyacağını, bunların arkasında tipik olarak hangi nedenlerin yattığını ve EXECUTIONS_TIMEOUT ile EXECUTIONS_TIMEOUT_MAX kullanarak instance'ına uygun temiz bir zaman sınırını nasıl ayarlayacağını gösterir. Güncelleme: Temmuz 2026.

Asılı kalan execution'ları nasıl anlarsın?

• "Executions" sekmesinde, benzer çalıştırmalar normalde saniyeler veya birkaç dakika içinde tamamlanmasına rağmen durum kalıcı olarak "Running" veya "Waiting" olarak kalır.
• Çalışma süresi göstergesi sürekli artar, ancak yeni log kayıtları veya node değişiklikleri görünmez.
• Queue modunda, bir worker asılı kalan execution tarafından bloke edildiği ve N8N_CONCURRENCY_PRODUCTION_LIMIT üzerinden yapılan yapılandırmaya göre paralel olarak başka çalıştırma başlatamadığı için yeni execution'lar kuyrukta birikir.
• Sunucu, mevcut yük ile açıklanamayacak şekilde belirgin biçimde daha fazla bellek veya CPU tüketir.

Tek başına asılı kalan bir çalıştırma başlangıçta zararsız görünür. Ancak pratikte, özellikle birden fazla workflow aynı worker pool'unu paylaştığında, tüm n8n instance'ını fark edilir şekilde yavaşlatmak için birkaç böyle execution yeterlidir.

Asılı kalan execution'ların tipik nedenleri

• Timeout ayarlanmamış: Kendi EXECUTIONS_TIMEOUT yapılandırman olmadan otomatik bir sınır devreye girmez, tek bir hatalı node tüm çalıştırmayı açık tutabilir.
• Kendi timeout'u olmayan dış çağrılar: Çok yavaş veya yanıt vermeyen bir API'yi bekleyen bir HTTP Request node'u, karşı taraf yanıt verene ya da n8n kendisi müdahale edene kadar askıda kalır.
• Yanlış yapılandırılmış Wait node'ları: Hiçbir zaman gerçekleşmeyen bir dış olayı bekleyen bir Wait node'u, execution'ı kalıcı olarak "Waiting" durumunda tutar.
• Asılı kalan alt workflow'lar (sub-workflow): Ana workflow'un bir alt workflow çağırırsa, onun takılması doğrudan üst çalıştırmaya yansır.
• Queue modunda sorunlar: Ana süreç ile worker arasındaki bağlantı, örneğin kararsız bir Redis erişimi nedeniyle bozulursa, worker onları artık fiilen işlemediği halde execution'lar "Running" durumunda kalır.

EXECUTIONS_TIMEOUT ve EXECUTIONS_TIMEOUT_MAX'ı doğru ayarlamak

Güvenilir bir zaman sınırı için workflow timeout yapılandırma kılavuzuna göre iki ortam değişkeni belirleyicidir:

• EXECUTIONS_TIMEOUT: Bireysel bir sınır belirlenmediği sürece tüm workflow'lar için geçerli olan varsayılan zaman sınırını saniye cinsinden belirler. Varsayılan değer -1'dir, yani devre dışıdır. 3600 değeri her çalıştırmayı bir saatle sınırlar.
• EXECUTIONS_TIMEOUT_MAX: Tek bir workflow kendi başına daha yüksek bir timeout belirlemiş olsa bile geçerli olan, saniye cinsinden mutlak üst sınırı tanımlar. Referansa göre varsayılan değer 3600 saniyedir.

Timeout'un teknik olarak nasıl devreye girdiğini anlamak için önemli: Workflow ana süreçte çalışıyorsa, dokümantasyona göre yumuşak bir timeout gerçekleşir ve bu, yalnızca o an aktif olan node tamamlandıktan sonra etkili olur. Execution bunun yerine ayrı bir süreçte, örneğin queue modunda bir worker üzerinde çalışıyorsa, n8n önce yine yumuşak bir sonlandırma dener ve ardından sert bir sonlandırmayı zorunlu kılar. Senin için bunun anlamı şudur: timeout anında bir kesme değil, sert müdahaleden önce devam eden işi mümkün olduğunca temiz şekilde bitiren kademeli bir mekanizmadır.

Tek tek workflow'lar kendi ayarlarında daha düşük bir timeout belirleyebilir. Ancak bu her zaman EXECUTIONS_TIMEOUT_MAX ile üstten sınırlandırılır, böylece tek bir workflow global sınırı aşamaz. Böylece her workflow'u ayrı ayrı güvence altına almak zorunda kalmadan maksimum çalışma süresi üzerindeki kontrolü elinde tutarsın.

Veritabanını hafif tutmak için execution verilerini temizlemek

Salt zaman sınırının ötesinde, execution verilerinin saklanmasına da bakmakta fayda var; çünkü aşırı dolu bir veritabanı asılı kalan çalıştırmaların teşhisini de zorlaştırır. Referansa göre n8n, execution verilerini otomatik olarak temizler:

• EXECUTIONS_DATA_PRUNE (varsayılan: etkin) tamamlanan execution'ların otomatik olarak silinip silinmeyeceğini belirler.
• EXECUTIONS_DATA_MAX_AGE eski execution'ların kaç saat sonra silinme adayı sayılacağını belirler, varsayılan değer 14 güne karşılık gelir.
• Durumu "new", "running" veya "waiting" olan aktif execution'lar temizlemenin dışında tutulur, aynı şekilde etiket veya değerlendirme eklediğin execution'lar da bu kapsamın dışındadır.

Bu koruma mekanizmaları iki ucu keskin bir kılıçtır: hâlâ çalışmakta olan bir execution'ın yanlışlıkla silinmesini önlerler, ancak aynı zamanda gerçekten asılı kalan bir execution da, bir timeout onu normal şekilde sonlandırmadığı sürece veritabanında kalıcı olarak kalır. Tam da bu yüzden, asılı kalan çalıştırmaların fark edilmeden birikmemesi için makul bir EXECUTIONS_TIMEOUT ile çalışan veri temizliğinin birleşimi önemlidir.

Pratik kontrol listesi

• Önce Executions sekmesinde hangi çalıştırmaların saatlerdir veya günlerdir gerçekten "Running" ya da "Waiting" durumunda kaldığını kontrol et.
• EXECUTIONS_TIMEOUT'u, en uzun düzenli workflow'ların için gerçekçi bir değere, artı bir güvenlik payına ayarla.
• EXECUTIONS_TIMEOUT_MAX'ı, özellikle uzun süren tekil workflow'ların bile sınırsız çalışamayacağı şekilde ayarla.
• HTTP Request veya Webhook bekleme noktaları gibi dışa bağlı node'larda, orada da ayrı bir timeout eklemenin mantıklı olup olmadığını kontrol et.
• Queue modunda ayrıca Redis bağlantısını ve worker'larının yükünü de takip et; çünkü asılı kalan bir worker, tek bir asılı workflow'dan çok farklı belirtilere yol açar.

n8n'i şirketinde dijital bir çalışan olarak işletiyorsan, temiz yapılandırılmış bir timeout, tıpkı concurrency limitlerine ve veri temizliğine dikkat etmek gibi temel donanımın bir parçasıdır. Bu ayarları bir kez doğru yapan kişi, genellikle artık asılı kalan execution'larla manuel olarak uğraşmak zorunda kalmaz. Bu konuda desteğe ihtiyacın varsa veya n8n instance'ını temelden daha kararlı hale getirmek istiyorsan, NordFlux sana şu konuda destek olur: n8n workflow'larının kurulumu ve işletilmesi.

Sık sorulan sorular

Bir n8n execution'ında "Waiting" durumu ne anlama gelir?

"Waiting", execution'ın workflow içindeki bir noktada bir Wait node'undan gelecek bir yanıt veya bekleyen bir webhook çağrısı gibi dış bir olayı beklediğini gösterir. Bu durum beklenen çalışma süresinin ötesinde kalıcı olarak devam ederse, bu, hiçbir zaman gerçekleşmeyen bir olaya işaret eder ve execution, bir timeout onu sonlandırana kadar fiilen askıda kalır.

EXECUTIONS_TIMEOUT için hangi değeri ayarlamalıyım?

Genel geçer doğru bir değer yoktur, bu en uzun düzenli workflow'larına bağlıdır. Başlangıç noktası olarak, en yoğun otomasyonunun normal çalışma süresini ölçüp bunu cömertçe, yaklaşık iki ile üç katına yuvarlamak faydalı olur. Böylece normal dalgalanmalar için yeterli tampon kalırken, gerçekten asılı kalan çalıştırmalar da güvenilir şekilde sonlandırılır.

EXECUTIONS_TIMEOUT bir execution'ı anında sonlandırır mı?

Hayır, n8n dokümantasyonuna göre önce yumuşak bir sonlandırma gerçekleşir. Ana süreçte n8n, o an çalışan node'un bitmesini bekler; ayrı süreçlerde ise yumuşak bir denemenin ardından kısa bir bekleme süresinden sonra ayrıca sert bir sonlandırma zorunlu kılınır. Yani geçiş ani değil, kademelidir.

Tek bir workflow, EXECUTIONS_TIMEOUT_MAX'ın izin verdiğinden daha yüksek bir timeout'a sahip olabilir mi?

Hayır. EXECUTIONS_TIMEOUT_MAX, tüm instance için mutlak üst sınırı tanımlar. Bir workflow kendi ayarlarında daha yüksek bireysel bir timeout belirlemiş olsa bile, bu değer EXECUTIONS_TIMEOUT_MAX tarafından kırpılır, böylece hiçbir workflow global sınırı aşamaz.

Asılı kalan execution'lar veritabanından otomatik olarak silinir mi?

Aktif oldukları sürece hayır. n8n, durumu "new", "running" veya "waiting" olan execution'ları EXECUTIONS_DATA_PRUNE üzerinden yapılan otomatik temizlemenin açıkça dışında tutar. Bu yüzden gerçekten asılı kalan bir execution, yapılandırılmış bir timeout onu sonlandırana ya da sen onu manuel olarak iptal edene kadar kalıcı olarak kalır.