Hallo,
Ich habe ein systematisches Problem bei meiner n8n Cloud-Instanz: Alle Code-Nodes schlagen mit „Task request timed out
Hey @Iheb_Tliba, während du auf eine Antwort wartest, findest du hier einige Dinge, die dir helfen könnten:
Empfohlene Ressourcen
Automatisch auf deine Frage abgestimmt.
Dokumentation:
Forum:
@mohamed3nan, @tamy.santos - ihr habt bei ähnlichen Problemen bereits geholfen, könnt ihr euch das anschauen?
Automatisch vorgeschlagen von n8n’s Community-Bot. Es ist ein Pilotprojekt - bitte teilt euer Feedback hier mit.
Hi @Iheb_Tliba Willkommen!
Diese Instanz ist nicht n8n Cloud. Cloud-Workspaces befinden sich auf app.n8n.cloud, während n8n-wsk.com WebSpaceKit’s verwaltetes n8n-Hosting ist, daher decken status.n8n.io und n8n-Support nichts dort ab und der Runner, der ausfällt, läuft in WebSpaceKit’s Container.
Die Nachricht mit einem trivialen Skript auf einem neuen Workflow bedeutet, dass der Task Broker keinen verbundenen Runner hat. Im Standard-internen Modus startet n8n den Runner als untergeordneten Prozess, und wenn dieser untergeordnete Prozess ständig abstürzt – Speicherdruck bei einem kleinen Plan ist die übliche Ursache – wartet jede Aufgabe die vollen 60 Sekunden und schlägt fehl, was auch zum Lauf passt, der 7h54m im Status „Running
Hi Iheb — ist das noch ungelöst?
Das Detail, das auffällt, ist, dass auch ein trivialer Code-Knoten ein Timeout verursacht, also sieht das nicht wie ein reines Stock-Sync-Skript-Problem aus. Es klingt eher, als würde der Code-Task-Runner keine Anfragen bearbeiten, oder der Runner-Prozess/Container schlägt fehl, bevor die Workflow-Logik überhaupt relevant wird.
Ich würde die Untersuchung in zwei Teile unterteilen, bevor du den WooCommerce/Cegid-Workflow änderst: ein kürzlich fehlgeschlagenes Ausführungsfenster und die Runner-/Hosting-Evidenz um dieselbe Zeit. Wenn der Runner das erste ist, das ausfällt, könnte das Neuaufbauen der Stock-Sync-Logik nur das eigentliche Problem verstecken.
Wenn du das Problem immer noch hast, wäre die nützliche Evidenz der fehlgeschlagene Ausführungs-Timestamp, Hosting-/Runtime-Logs um diese Minute herum, und ob ein neuer Workflow mit nur return [{ json: { test: 1 } }]; immer noch fehlschlägt.