n8n Cloud: Executions hängen auf „Queued / Starting soon“?

Rückstau und Speicherfehler getrennt bewerten

Ein Originalbericht zu n8n Cloud 2.32.7 verbindet dauerhaft wartende Ausführungen mit Abstürzen bei einem Webhook-Burst. Das belegt dieses gemeldete Fehlerbild, aber keine allgemeine Ursache für jeden Rückstau. Q1 n8n dokumentiert für Cloud eine Begrenzung gleichzeitig laufender Produktionsausführungen und eine Warteschlange. Wartende Ausführungen lassen sich nicht einfach wie fehlgeschlagene Läufe erneut versuchen. Q2

Eine Warteschlange ist daher zunächst eine Zustandsbeschreibung. Ob Kapazität belegt ist, eine Ausführung festhängt oder ein anderer Plattformfehler vorliegt, muss aus Zeitverlauf und Statusdaten hervorgehen.

Rückstau nachvollziehbar untersuchen

1. Bestand erfassen. Notiere die ältesten wartenden IDs, Workflow, Eingangszeit und Anzahl neu hinzugekommener Einträge. Vergleiche dies mit tatsächlich laufenden Ausführungen. Das Alter allein erklärt noch nicht die Ursache.
2. Fachliche Referenzen sichern. Verknüpfe jeden wartenden Geschäftsvorgang mit seiner Quell-ID. Prüfe bei unklarem Status im Ziel, ob er bereits verarbeitet wurde. Eine später doch startende Queue-Ausführung darf nicht mit einem manuellen Replay konkurrieren.
3. Lastprofil erfassen. Vergleiche ruhige Zeiträume mit dem Ausfallfenster: Ereignisse pro Zeitraum, Payload-Größe, Binärdateien, Ergebnisumfang und Laufdauer. Eine große Nutzlast kann anders wirken als viele kleine Jobs.
4. Kontrolliertes Beispiel nutzen. Teste einen kleinen, harmlosen Datensatz über den veröffentlichten Produktionstrigger eines getrennten Workflows. Ein manueller Editorlauf prüft nicht dieselbe Produktionswarteschlange. Wird auch dieser trotz verfügbar scheinender Kapazität nicht gestartet, ist das ein hilfreicher Supportbefund. Es rechtfertigt keine eigenmächtige Datenbankkorrektur in Cloud.
5. Mit Belegen eskalieren. Übergib Instanz, Plan, Version, IDs, Zeitfenster und beobachtete Neustarts. Wenn Abbruchfunktionen nicht wirken, dokumentiere das mit dem ursprünglichen Status statt mehrfach neue Abbrüche oder Läufe zu erzeugen.

Gezielte Entlastung

Nach bestätigter Lastursache kann eine kontrollierte Annahme, kleinere Verarbeitungseinheiten oder eine besser begrenzte Datenmenge sinnvoll sein. Eine größere Kapazität kann helfen, ersetzt aber nicht den Abgleich der wartenden Vorgänge. Löschen bedeutet unter Umständen den Verlust noch erforderlicher Arbeit und braucht deshalb eine dokumentierte Entscheidung pro Ereignis.

Häufige Fragen

Kann ich alle Ereignisse nochmals senden?

Erst nach Klärung ihrer bisherigen Verarbeitung. Wartende oder gerade gestartete Kopien können später ebenfalls erfolgreich werden.

Beweist ein OOM-Fehler die Ursache jeder alten Queue-Zeile?

Nein. Stelle zeitlichen Zusammenhang und betroffene Ausführungen getrennt fest. Ein alter hängender Eintrag und eine aktuelle Lastspitze können verschiedene Probleme sein.

Unterstützung für diesen Fall

Wir helfen dir, den betroffenen Ablauf einzugrenzen und die nächste Maßnahme kontrolliert vorzubereiten. Fall A0167 mit KAN KAI WORKS besprechen.