Describe the problem/error/question
Mein Workflow verarbeitet PDF-Dateien (Download → Text extrahieren über den Node „Extract From File
Hallo @zyll
Basierend auf den Symptomen, die du beschrieben hast, handelt es sich nicht um einen Standard-„Node-Fehler,
Hallo @zyll Willkommen!
Die automatische Deaktivierung ist ein erwartetes Verhalten von n8n Cloud, kein Konfigurationsproblem: Ein Prozess-Level-Crash (OOM/SIGKILL oder ein nativer Crash im PDF-Parser) löst eine beabsichtigte Sicherheitsdeaktivierung aus. Da es sich um einen Hardcrash statt um einen Node-Fehler handelt, wird auch dein Error Workflow umgangen, weshalb nichts gespeichert wird und kein Alert ausgelöst wird. Es gibt keine Workflow-Level-Einstellung, um dies in Cloud auszuschalten. Da ein Crash keinen Error Workflow auslöst und Audit-Log-Streaming nur für Enterprise verfügbar ist, besteht die Starter-kompatible Möglichkeit, nicht mehr überrascht zu werden, darin, den aktiven Status des Workflows von einem externen Scheduler abzufragen und ihn über die n8n API reaktivieren, was ihn auch von deinem Execution-Kontingent fernhält.
Siehe dies:
kjooleng’s OOM-Analyse ist richtig, aber dein eigenes Detail (sporadisch, bei derselben Datei) grenzt das tatsächlich stark ein, denn eine Datei, die einfach zu groß ist, schlägt jedes Mal fehl, nicht manchmal. Identische Eingaben, die nur gelegentlich fehlschlagen, sind die Signatur von nebenläufigkeitsgekoppeltem Speicher: Die PDF-Extraktion drückt die Instanz nur dann über die RAM-Obergrenze des Starter-Plans, wenn sie zufällig gleichzeitig mit anderen Ausführungen läuft. In einer ruhigen Minute passt sie, in einer beschäftigten Minute führt dieselbe Datei zu OOM. Deshalb sieht es zufällig aus, und deshalb wird „das PDF optimieren
Protokolliere die Dateigröße, Seitenzahl und Knotenspeichernutzung bei erfolgreichen und fehlgeschlagenen Ausführungen. Wenn die gleiche PDF nur zeitweise fehlschlägt, können die Ausführungsdaten ein Ressourcenlimit oder Timeout anstatt fehlerhafter Inhalte anzeigen.
Versuche zusätzlich zum Drosseln der Concurrency, „Extract From File
@colemaffeo6 hat die richtige Form für das zweite Symptom benannt — ein geplanter Watchdog, der in der öffentlichen API aktiv liest. Ich habe das vor ein paar Tagen für meine eigenen Instanzen gebaut, also hier ist es als funktionierendes Ding und nicht nur als Beschreibung davon.
Warum diese Hälfte überhaupt zum Tooling wert ist: Ein harter Crash beendet den Prozess, bevor der Error Workflow ausgelöst werden kann, also ist der eine Mechanismus, der dir bescheid sagen soll, derjenige, der es nicht kann. Und die Auto-Deaktivierung ist korrektes Verhalten — sie stoppt eine Crash-Schleife — es ist nur still, und Stille ist nicht zu unterscheiden von Funktionieren.
So funktioniert es:
- snapshot erfasst, welche Workflows derzeit aktiv sind — das wird zur erwarteten Menge.
- check ruft den Live-Status ab und beendet mit 1, wenn einer von ihnen nicht mehr aktiv ist.
- Cron führt check aus, und der Exit-Code treibt jedes Alerting an, das du bereits hast — Healthchecks.io, einen curl zu deinem eigenen Webhook, alles, das einen Status liest.
Eine Sache, bei der ich meine Meinung während des Baus änderte: Ich ließ die Reaktivierung weg. Das Umschalten des Workflows nach einem Speicher-Kill führt die gleiche Datei in die gleiche Grenze, also bekommst du an einem schlechten Tag einen flattermden Workflow und eine stillere Version des gleichen Ausfalls. Es zählt stattdessen Abfälle, und sobald einer mehrmals abgefallen ist, sagt es bescheid, denn an diesem Punkt ist die Antwort das Concurrency-Profil, nicht der An-Schalter. Wenn deine Crashes selten und unabhängig von der Last sind, ist eine Reaktivierung der bessere Kompromiss und es ist eine kurze Funktion zum Hinzufügen.
Wo es bricht: Dein Polling-Intervall ist dein Blindfenster, also alle fünf Minuten prüfen bedeutet bis zu fünf Minuten etwas zu sammeln bevor irgend jemand bescheid weiß. Und es kann einen Crash nicht von dir unterscheiden, der etwas bewusst ausschaltet — snapshot nach einer beabsichtigten Änderung erneut ausführen, oder es wird dich über deine eigene Bearbeitung benachrichtigen.
Nur Stdlib. Benötigt einen API-Schlüssel aus Settings > n8n API; die öffentliche API ist in der kostenlosen Testversion nicht verfügbar, also ist eine 401 dort normalerweise der Plan und nicht der Schlüssel.
Keine Lösung für den Crash selbst, könnte dir aber helfen, zu sehen, was sonst noch gefährdet ist —
lade deine exportierte Workflow-JSON in diesen Scanner und er kennzeichnet Nodes
mit continueRegularOutput, fehlenden Error-Branches, keinem Retry/Timeout,
unauthentifizierten Webhooks, hardcodierten Anmeldedaten.
Da lastNodeExecuted vor dem Crash-Punkt stoppt, lohnt es sich zu prüfen,
ob die Fehlerbehandlung dieses Nodes den Fehler stumm verschluckt.
Browser-lokal, keine Anmeldung, kein Upload.
danke für die hilfe an alle, es funktioniert jetzt