Concurrency (Eşzamanlılık) Kontrolü (Cloud Limitleri: Starter 5 / Pro 20 Paralel)

n8n Cloud'da her plan, kaç workflow çalıştırmasının aynı anda çalışabileceğini sınırlar: Starter plan 5 paralel çalıştırmaya izin verir, Pro plan 20'ye, ve Enterprise seviyesi n8n fiyatlandırma genel bakışına göre 200 veya daha fazla paralel çalıştırma seviyesindedir. Limit aşıldığında n8n, ek çalıştırmaları otomatik olarak bir kuyruğa alır ve tekrar kapasite boşaldığında bunları FIFO prensibine göre işler. Düzenli olarak büyük veri hacimleri işleyen şirketler için, örneğin toplu içe aktarmalar, toplu e-posta gönderimleri veya webhook tetikleyicileri üzerinden uzun listelerin işlenmesi gibi durumlarda, bu limit bir workflow oluşturulmadan önce bilinmesi gereken bir faktördür, aksi takdirde çalıştırmalar fark edilmeden kuyrukta birikebilir. Durum: Temmuz 2026.

n8n Cloud'da concurrency limiti nasıl çalışır

Sınırlama, n8n'in Cloud concurrency ile ilgili dokümantasyonuna göre yalnızca üretim (production) çalıştırmaları için geçerlidir, yani bir webhook veya bir tetikleyici düğüm tarafından başlatılanlar için. Manuel test çalıştırmaları, alt workflow'lar (sub-workflow) ve hata workflow'ları buna dahil değildir ve limitten bağımsız olarak çalışmaya devam eder. Eşzamanlı üretim çalıştırmalarının sayısı plan değerini aşarsa, ek çalıştırmalar reddedilmez, bunun yerine bir kuyrukta bekler. Pratikte önemli olan: bekleyen çalıştırmalar yeniden denenemez (retry yoktur) ve bekleyen bir çalıştırmayı iptal eden kişi onu kuyruktan tamamen kaldırır. Bir instance yeniden başlatıldıktan sonra n8n, bekleyen çalıştırmaları kapasite sınırına kadar yeniden devam ettirir ve geri kalanını tekrar kuyruğa alır. Güncel doluluk durumu, bir projenin veya workflow'un çalıştırmalar sekmesinde doğrudan görülebilir.

Toplu işleme üzerindeki etkisi

Örneğin, bir webhook üzerinden 500 kaydı tek tek ayrı çalıştırmalar olarak tetikleyen biri, n8n'in kendisi herhangi bir hata mesajı göstermese bile, Starter planında ilk 5 eşzamanlı çalıştırmadan sonra otomatik olarak bir kuyrukla karşılaşır. Bu, genel işlemeyi geciktirir ancak kimse bekleyen çalıştırmaları iptal etmediği sürece veri kaybına yol açmaz. Bu durum, örneğin harici bir sistemin hızlı bir yanıt beklediği ve kuyruğun yanıt süresini öngörülemez şekilde uzattığı zaman kritik süreçlerde daha kritik hale gelir. Instance yeniden başlatmalarında da (örneğin bakım pencereleri nedeniyle) kuyruk, işlenmeden önce kısa süreliğine daha da büyüyebilir.

Batching ile geçici çözümler

Birçok tekil üretim çalıştırmasını paralel olarak tetiklemek yerine, yük tek bir workflow içinde kontrol edilebilir. Pratikte yaygın yaklaşımlar:

• Split in Batches kullanmak: kayıtlar, her kayıt için ayrı bir üretim çalıştırması başlatmak yerine, tek bir workflow çalıştırması içinde gruplar halinde işlenir. Bu, eşzamanlı çalıştırma sayısını belirgin şekilde azaltır.
• Bekleme süreleri planlamak: batch'ler arasındaki bir Wait düğümü, n8n'in dahili kuyruğuna ek olarak alt sistemleri (örneğin kendi rate limit'leri olan API'ler) rahatlatır.
• Alt workflow'lar kullanmak: dokümantasyona göre alt workflow (sub-workflow) çalıştırmaları concurrency limitine dahil olmadığından, işleme mantığı kısmen, aynı anda daha az sayıda üst düzey üretim çalıştırması oluşacak şekilde yapılandırılabilir.
• Tetikleyici sıklığını azaltmak: toplu yüklemelerde, tetikleyen süreci (örneğin bir cron görevi veya önceden yapılan bir içe aktarma) eşzamanlı webhook çağrılarının sayısını baştan itibaren plan limitinin altında tutacak şekilde ayarlamak faydalıdır.

Dürüst olmak gerekirse, bu püf noktalarından hiçbiri, kalıcı olarak daha fazla gerçek paralellik gerektiğinde daha yüksek bir plan seviyesinin yerini tutmaz. Batching yükü zaman içinde kaydırır ancak ek kapasite yaratmaz.

Kendi barındırma (self-hosted): limit üzerinde tam kontrol

n8n'i kendisi işleten kişinin daha fazla esnekliği vardır: n8n'in concurrency kontrolüyle ilgili dokümantasyonuna göre, self-hosting'de sınırlama varsayılan olarak devre dışıdır ve kuyruk modunda dahil olmak üzere N8N_CONCURRENCY_PRODUCTION_LIMIT ortam değişkeni üzerinden özel olarak ayarlanabilir. Bu, kendi altyapısı üzerinde daha fazla kontrol anlamına gelir, ancak aynı zamanda daha fazla kişisel sorumluluk da getirir: bilinçli olarak belirlenmiş bir limit olmadan, bir instance ani bir yük artışında aşırı yüklenebilir. Tam olarak bu noktada, örneğin bir Cloud planının mı yoksa kendi altyapısının mı bir şirketin gerçek veri hacmine ve kontrol gereksinimlerine uygun olduğuna karar verirken, sağlam bir konsept devreye girer. NordFlux, tam olarak bu değerlendirme konusunda n8n danışmanlığı kapsamında destek sağlar.

n8n'de concurrency kontrolü hakkında sıkça sorulan sorular

Limiti aşan çalıştırmalara ne olur?

Reddedilmezler, bunun yerine otomatik olarak bir kuyruğa alınırlar ve kapasite tekrar boşaldığında geliş sırasına göre (FIFO) işlenirler.

Limit manuel test çalıştırmaları için de geçerli mi?

Hayır. Dokümantasyona göre, n8n Cloud'daki concurrency limiti yalnızca webhook veya tetikleyici düğüm üzerinden yapılan üretim çalıştırmalarını etkiler. Manuel çalıştırmalar, alt workflow'lar ve hata workflow'ları bunun dışındadır.

Bekleyen bir çalıştırmayı sadece yeniden başlatabilir miyim?

Hayır, bekleyen çalıştırmalar yeniden denenemez (retry). Onları iptal eden kişi, onları kuyruktan tamamen kaldırır ve bunların yeniden tetiklenmesi gerekir.

Concurrency limiti nedeniyle Pro plana yükseltmek mantıklı mı?

Bu, gerçek işlem hacmine bağlıdır. Düzenli olarak 5'ten belirgin şekilde daha fazla eşzamanlı üretim çalıştırmasına ihtiyaç duyan kişi, Starter planında kuyruk kaynaklı gecikmeleri daha sık yaşar. Batching bunu hafifletebilir, ancak kalıcı olarak yüksek hacimde daha yüksek bir plan seviyesinin yerini tutmaz.