Problem/Fehler/Frage beschreiben
Absturz des n8n-Cloud-Instanz-Workflows.
Mein Workflow läuft seit den letzten 3 Monaten einwandfrei, aber gestern ist er plötzlich 3 Mal fehlgeschlagen und n8n hat ihn automatisch ausgeschaltet. Es gab Vorfälle, bei denen das System über 30 Ausführungen fehlgeschlagen ist, wurde aber nie ausgeschaltet. Dies wurde nach 3 Fehlern ausgeschaltet. Außerdem habe ich die Knoten, bei denen der Fehler auftrat, 3 Mal erneut versucht, aber es ist trotzdem abgestürzt, weil der Speicherplatz ausging. In der Dokumentation heißt es, dass n8n die Instanz automatisch neu startet, aber das ist auch nicht passiert – ich musste sie heute nach einem Tag manuell neu starten. Welche Vorsichtsmaßnahmen kann ich für die Zukunft treffen?
Welche ist die Fehlermeldung (falls vorhanden)?
Ausführung an diesem Knoten gestoppt
n8n könnte während der Ausführung dieser Operation nicht genügend Speicher gehabt haben. Mehr Kontext und Tipps zur Vermeidung in der Dokumentation
Bitte teile deinen Workflow
(Wähle die Knoten auf deiner Arbeitsfläche aus und verwende die Tastenkombinationen CMD+C/STRG+C und CMD+V/STRG+V zum Kopieren und Einfügen des Workflows.)
Ausgabe des letzten Knotens teilen
Informationen zu deinem n8n-Setup
- n8n-Version:
- Datenbank (Standard: SQLite):
- n8n EXECUTIONS_PROCESS-Einstellung (Standard: own, main):
- n8n wird ausgeführt über (Docker, npm, n8n cloud, Desktop-App):
- Betriebssystem:
Hallo @Aarush_Bisht
Um speicherbezogene Abstürze zu verhindern, solltest du dich darauf konzentrieren, den „Memory Footprint
Es funktionierte monatelang einwandfrei, stürzte dann aber eines Tages ab/wurde unveröffentlicht, nur nachdem 3 verschiedene Ausführungen fehlgeschlagen waren. (Ich habe 3 Wiederholungsversuche pro Node pro Ausführung implementiert). Die Datenmenge ist auch nicht groß (buchstäblich nur 50-60 Zeilen Mitarbeiterdaten). Ich habe auch Fehlerbehandlung implementiert – ich habe „immer Daten ausgeben
Trifft eines dieser Punkte zu:
- Unerwartet großes Payload: Hatte einer dieser 60 Mitarbeiter ein Feld (z. B. einen Abschnitt „Notizen
50-60 Zeilen Daten waren für einen Mitarbeiter.
und einer der 3, die fehlgeschlagen waren, war ein JavaScript-Code-Node, in dem ich selbst versuchte, die Datendimensionen zu reduzieren.
{
“nodes”: [
{
“parameters”: {
“jsCode”: “\nconst updates = $node[“Webhook”].json.body.data.fieldUpdatesIds.map(f => f.id);\n\nconst targetFields = [\n “work.site”,\n “work.department”,\n “work.siteId”,\n “work.customColumns.column_1732603686850”,\n “work.workChangeType”,\n “work.title”,\n “work.activeEffectiveDate”,\n “work.reportsTo”,\n “root.displayName”\n];\n\nconst check = updates.some(id => targetFields.includes(id));\n\nreturn [{ check}];\n”
},
“type”: “n8n-nodes-base.code”,
“typeVersion”: 2,
“position”: [
-3104,
496
],
“id”: “7e8b7768-aa58-4218-98bb-24008a7ea4ef”,
“name”: “Code in JavaScript1”
}
],
“connections”: {
“Code in JavaScript1”: {
“main”: [
]
}
},
“pinData”: {},
“meta”: {
“instanceId”: “0f39d8fdd402ddce20d0eb724526828e8c2d8679170e3a08fe6cd471c799fab6”
}
}
Logs für diese 3 Ausführungen können nicht überprüft werden, da n8n sagt, dass Logs aufgrund des Ausführungsfehlers nicht gespeichert werden. (Seltsam, da Logs von Fehlern wichtiger sind).
1 Node schlug fehl, der nur zum Abrufen eines Auth-Tokens vorhanden war. Keine Schleife, nur ein API-Aufruf. Der dritte (HTTP-Node) hatte einige imageUrls in der Antwort, aber keine Bilder (basierend auf früheren Ausführungen). Alle drei sind in 3 verschiedenen Ausführungen mit demselben Grund zusammen fehlgeschlagen.
Könnte es ein Fehler auf der Seite von n8ns Server sein?
Sehr unwahrscheinlich.
Dein Code ist logisch einfach und sollte einen Server mit 60 Zeilen Daten nicht zum Absturz bringen. Es gibt jedoch ein Performance-Risiko in der Art, wie er auf Daten zugreift:
const updates = $node["Webhook"].json.body.data.fieldUpdatesIds.map(f => f.id);
Die Verwendung von $node["NodeName"] zwingt n8n, das gesamte Datenobjekt dieses vorherigen Knotens für die Dauer des Workflows im aktiven Speicher zu halten. Wenn deine Webhook-Payload groß ist und mehrere Knoten dies tun, vervielfachst du den Speicherverbrauch.
Ersetze deinen aktuellen JS-Code durch diese Version. Sie verwendet moderne Syntax und fügt eine „Sicherheitsprüfung
Ich habe gerade nach fehlgeschlagenen Ausführungen gesucht – es war die Standardspeicherung. Die JSON-Daten enthielten nur Bild-URLs und sonst nicht viel. Ich habe mir auch die Daten angesehen, die alle Knoten vom Webhook erhalten (ja, dieser Code-Knoten verarbeitete diese Daten). Es ist ein einfacher Slack-Event-Webhook, der 20–30 Zeilen von API-Request-Metadaten (in den Headern) und 10 Zeilen vom Body sowie einige andere Informationen in JSON empfängt. (Nichts scheint falsch zu sein.) Mein Problem ist, dass wenn ich irgendwann in den Urlaub gehe und das passiert, das System eine Weile lang ausfallen könnte.
Kann ich etwas tun, um kumulative Speicherlecks zu beheben? Wie zum Beispiel den Workflow neu starten oder ähnliches? Das Ausschalten bei erfolgreichen Iterationen könnte für mich keine Option sein (Unternehmensinstanz, daher muss ich zumindest die vollständigen Datensätze der letzten Tage behalten.) Concurrency könnte möglicherweise ein Problem sein, da alle 3 fehlgeschlagenen Ausführungen zusammen aufgetreten sind (aber ich habe schon gesehen, dass n8n 8-10 oder sogar mehr gleichzeitig verwaltet hat). Externe Überwachung könnte nicht nötig sein, da n8n selbst eine Nachricht per E-Mail sendet, dass sie es ausgeschaltet haben und wir benachrichtigt werden. (Ich meinte, wer nimmt seinen Büro-Laptop mit in den Urlaub 
)
Der Workflow selbst neu zu starten wird einen Leak nicht beheben; der Zurücksetzen-Punkt ist die laufende Instanz oder der Worker. Für diesen Fall ist der aussagekräftigere Hinweis, dass die drei Fehler zusammen auftraten, nicht dass der Code-Knoten ressourcenintensiv ist.
Überprüfe ein Fenster, keine Mitarbeiterdaten nötig: Haben die drei Slack-Webhook-Ausführungen innerhalb weniger Sekunden gestartet, und waren in diesem Moment andere Ausführungen aktiv? Wenn ja, ist die nächste Grenze ein kleiner Queue/Serial Gate vor dem Pfad der Mitarbeiteraktualisierung, sodass Slack schnell bestätigt wird, aber nur ein Update-Job gleichzeitig verarbeitet wird. Falls sie zeitlich verteilt waren, behandle es als Cloud-/Runtime-Vorfall und gebe dem Support die drei Ausführungs-IDs plus den Auto-Deaktivierungs-Zeitstempel.
könnte ein Problem mit Concurrency sein. Gibt es eine Möglichkeit, damit umzugehen? Können wir Ausführungen, die gleichzeitig ankommen, um etwas zeitverzögern?
Ja, aber lege die Verzögerung nicht nach den großen Nodes. Wenn drei Slack-Events bereits den vollständigen Workflow gestartet haben, lässt ein Wait-Node einfach drei Ausführungen gleichzeitig am Leben.
Halte die Slack-Aufnahme klein: Empfange das Event, bestätige es und platziere nur die Event-ID/den Event-Body, die für das Employee-Update notwendig sind, hinter einem One-at-a-time-Gate. Verarbeite dann diesen zweiten Teil nach einem Zeitplan oder in einer Warteschlange. Du kannst weiterhin Ausführungsprotokolle speichern; das zu reduzieren ist parallele Arbeit im Employee-Update-Branch, nicht die Aufbewahrung von Protokollen selbst.
Ich vermute, das Event war bereits klein, da die Webhook-Daten nicht groß waren (max. 50-60 Zeilen JSON) und wir nur wenige Felder davon benötigten (was der Code-Node tat – Dimensionalitätsreduktion von Daten). Es ist nur so, dass die Anfrage einfach parallel eingegangen ist. Ich habe https-Anfragen gesehen, die MBs an Daten erhielten und trotzdem nicht abgestürzt sind. Jedenfalls werde ich versuchen, das an das n8n-Team weiterzuleiten (wenn es für mich möglich ist). Danke für die Hilfe, ich werde versuchen, diese Vorschläge in zukünftigen Workflows umzusetzen.
