Concurrency steuern (Cloud-Limits: Starter 5 / Pro 20 parallel)

In n8n Cloud begrenzt jeder Tarif, wie viele Workflow-Ausführungen gleichzeitig laufen dürfen: Der Starter-Plan erlaubt 5 parallele Ausführungen, der Pro-Plan 20, und die Enterprise-Stufe liegt laut n8n-Preisübersicht bei 200 oder mehr parallelen Ausführungen. Wird das Limit überschritten, reiht n8n weitere Ausführungen automatisch in eine Warteschlange ein und arbeitet sie nach dem FIFO-Prinzip ab, sobald wieder Kapazität frei wird. Für Unternehmen, die regelmäßig größere Datenmengen verarbeiten, etwa Massen-Imports, Bulk-Mailings oder das Abarbeiten langer Listen über Webhook-Trigger, ist diese Grenze ein Faktor, den man vor dem Bau eines Workflows kennen sollte, sonst stauen sich Ausführungen unbemerkt in der Warteschlange. Stand: Juli 2026.

Wie die Concurrency-Grenze in n8n Cloud funktioniert

Die Begrenzung gilt laut der n8n-Dokumentation zur Cloud-Concurrency ausschließlich für produktive Ausführungen, also solche, die durch einen Webhook oder einen Trigger-Node gestartet werden. Manuelle Testläufe, Sub-Workflows und Fehler-Workflows zählen nicht mit und laufen unabhängig vom Limit weiter. Überschreitet die Zahl gleichzeitiger produktiver Ausführungen den Plan-Wert, werden weitere Läufe nicht abgelehnt, sondern warten in einer Warteschlange. Wichtig für die Praxis: Wartende Ausführungen lassen sich nicht erneut anstoßen (kein Retry), und wer eine wartende Ausführung abbricht, entfernt sie komplett aus der Warteschlange. Nach einem Neustart der Instanz nimmt n8n die wartenden Läufe bis zur Kapazitätsgrenze wieder auf und reiht den Rest erneut ein. Den aktuellen Auslastungsstand sieht man direkt im Ausführungen-Tab eines Projekts oder Workflows.

Auswirkung auf Massenverarbeitung

Wer beispielsweise 500 Datensätze über einen Webhook einzeln als separate Ausführungen anstößt, bekommt im Starter-Plan nach den ersten 5 gleichzeitigen Läufen automatisch eine Warteschlange, auch wenn n8n selbst keine Fehlermeldung zeigt. Das verzögert die Gesamtverarbeitung, ist aber kein Datenverlust, solange niemand die wartenden Ausführungen abbricht. Kritischer wird es bei zeitkritischen Prozessen, etwa wenn ein externes System eine schnelle Antwort erwartet und die Warteschlange die Reaktionszeit unvorhersehbar verlängert. Auch bei Instanz-Neustarts (zum Beispiel durch Wartungsfenster) kann sich die Warteschlange kurzzeitig weiter aufbauen, bevor sie abgearbeitet wird.

Workarounds über Batching

Statt viele einzelne produktive Ausführungen parallel auszulösen, lässt sich die Last innerhalb eines Workflows steuern. Gängige Ansätze in der Praxis:

• Split in Batches nutzen: Datensätze werden innerhalb eines einzelnen Workflow-Laufs in Gruppen verarbeitet, statt für jeden Datensatz eine eigene produktive Ausführung zu starten. Das reduziert die Zahl gleichzeitiger Ausführungen deutlich.
• Wartezeiten einplanen: Ein Wait-Node zwischen Batches entlastet nachgelagerte Systeme (zum Beispiel APIs mit eigenen Rate-Limits) zusätzlich zur n8n-internen Warteschlange.
• Sub-Workflows einsetzen: Da Sub-Workflow-Ausführungen laut Dokumentation nicht in die Concurrency-Grenze einfließen, lässt sich Verarbeitungslogik teilweise so strukturieren, dass weniger produktive Top-Level-Ausführungen gleichzeitig entstehen.
• Trigger-Frequenz drosseln: Bei Massen-Uploads lohnt es sich, den auslösenden Prozess (zum Beispiel ein Cronjob oder ein vorgeschalteter Import) so zu takten, dass er die Zahl gleichzeitiger Webhook-Aufrufe von vornherein unter dem Plan-Limit hält.

Ehrlich betrachtet ersetzt keiner dieser Kniffe eine höhere Plan-Stufe, wenn dauerhaft mehr echte Parallelität gebraucht wird. Batching verschiebt die Last zeitlich, es schafft aber keine zusätzliche Kapazität.

Selbst gehostet: eigene Kontrolle über die Grenze

Wer n8n selbst betreibt, hat mehr Spielraum: Laut der n8n-Dokumentation zur Concurrency-Steuerung ist die Begrenzung im Self-Hosting standardmäßig deaktiviert und lässt sich über die Umgebungsvariable N8N_CONCURRENCY_PRODUCTION_LIMIT gezielt setzen, auch im Queue-Modus. Das bedeutet mehr Kontrolle über die eigene Infrastruktur, aber auch mehr Eigenverantwortung: Ohne bewusst gesetztes Limit kann eine Instanz bei einem plötzlichen Lastspitze überlastet werden. Genau an dieser Stelle setzt eine saubere Konzeption an, etwa bei der Frage, ob Cloud-Plan oder eigene Infrastruktur zur tatsächlichen Datenmenge und den Kontrollanforderungen eines Unternehmens passt. NordFlux unterstützt bei genau dieser Einschätzung im Rahmen der n8n-Beratung.

Häufige Fragen zu Concurrency-Steuerung in n8n

Was passiert mit Ausführungen, die das Limit überschreiten?

Sie werden nicht verworfen, sondern automatisch in eine Warteschlange gestellt und in der Reihenfolge ihres Eintreffens (FIFO) verarbeitet, sobald wieder Kapazität frei ist.

Gilt das Limit auch für manuelle Testläufe?

Nein. Die Concurrency-Grenze in n8n Cloud betrifft laut Dokumentation nur produktive Ausführungen über Webhook oder Trigger-Node. Manuelle Ausführungen, Sub-Workflows und Fehler-Workflows sind ausgenommen.

Kann ich eine wartende Ausführung einfach erneut starten?

Nein, wartende Ausführungen lassen sich nicht per Retry erneut anstoßen. Wer sie abbricht, entfernt sie vollständig aus der Warteschlange, sie muss dann neu ausgelöst werden.

Lohnt sich ein Upgrade auf den Pro-Plan wegen der Concurrency-Grenze?

Das hängt vom tatsächlichen Verarbeitungsvolumen ab. Wer regelmäßig deutlich mehr als 5 gleichzeitige produktive Ausführungen braucht, spürt im Starter-Plan häufiger Warteschlangen-Verzögerungen. Batching kann das abfedern, ersetzt bei dauerhaft hohem Volumen aber keine höhere Plan-Stufe.