n8n geht auf dem VPS offline: Ursachen erkennen

Warum n8n offline geht: vier Fehler, ein Symptom

„n8n geht ständig offline“ kann vier verschiedene Fehler bedeuten. Jeder Fehler erfordert eine andere Behebung. Der Editor zeigt einen Hinweis über eine verlorene Verbindung an, während der Container normal läuft. Der Container startet selbstständig neu. Der Kernel beendet den Node.js-Prozess, weil er zu viel Arbeitsspeicher verwendet. Oder der Prozess ist überhaupt nicht fehlerhaft, und ein aktiver Workflow wird einfach nie ausgelöst. Wenn Sie die falsche Einstellung ändern, verbringen Sie ein ganzes Wochenende mit einem Problem, das gar nicht existiert.

Ermitteln Sie daher zuerst, welcher Fehler vorliegt, bevor Sie eine Konfiguration ändern. n8n läuft als einzelner Node.js-Prozess, normalerweise in einem Docker-Container hinter einem Reverse Proxy, der TLS (Transport Layer Security) terminiert. Jede dieser Ebenen kann auf eigene Weise ausfallen. Der Browser meldet sie jedoch alle mit derselben Nachricht.

Diagnose in dieser Reihenfolge

Führen Sie diese Befehle auf dem VPS (Virtual Private Server) aus und lesen Sie die Werte ab, die Ihre eigene Maschine ausgibt. Vergleichen Sie sie nicht mit Zahlen aus einem Forenbeitrag. Die hier relevanten Werte beschreiben Ihr System, nicht das eines anderen.

docker ps -a --filter name=n8n
docker logs --tail 200 --timestamps n8n
docker inspect n8n | grep -iE 'Status|Running|RestartCount|OOMKilled|ExitCode'
docker stats --no-stream

Die Spalte STATUS aus docker ps -a zeigt, wie lange sich der Container bereits in seinem aktuellen Zustand befindet. Vergleichen Sie diesen Zeitpunkt mit dem Beginn Ihres Problems. Wenn der Container bereits lange vor dem Erscheinen des Banners aktiv war, war n8n nie offline. Gestört ist dann die Verbindung zwischen Ihrem Browser und dem Backend. Dabei handelt es sich um den WebSocket-Pfad, der im nächsten Abschnitt behandelt wird.

RestartCount gibt an, wie oft Docker diesen Container neu gestartet hat. Notieren Sie die Zahl, warten Sie eine Minute und lesen Sie sie erneut ab. Steigt die Zahl während Ihrer Beobachtung, liegt eine Neustartschleife vor. Die Logzeilen unmittelbar vor jedem Neustart enthalten den Grund.

OOMKilled ist ein Wahr/Falsch-Flag. true bedeutet, dass der Linux-Kernel den Prozess beendet hat, weil er ein Speicherlimit überschritten hat. Dabei kann es sich um das Limit des Containers oder der gesamten Maschine handeln. Dieses einzelne Feld unterscheidet eine Speicherbeendigung von jeder anderen Art des Prozessendes. Deshalb lesen Sie es, bevor Sie eine Ursache vermuten.

ExitCode enthält den Exit-Code, mit dem Ihr Container zuletzt beendet wurde. Sie müssen sich nicht merken, wofür jeder Code steht. Lesen Sie Ihren Wert ab und anschließend das Ende von docker logs mit demselben Zeitstempel. Das Log-Ende und das Out-of-Memory-Flag zeigen gemeinsam, was passiert ist. Jeder Wert für sich kann jedoch irreführend sein.

docker stats zeigt die aktuelle Speichernutzung neben dem geltenden Limit. Lassen Sie den Befehl in einem zweiten Terminal laufen, lösen Sie den Workflow aus, bei dem der Fehler auftritt, und beobachten Sie, wie sich der Wert während des Fehlers verändert.

Das Banner „Verbindung verloren“ wird normalerweise von Ihrem Reverse Proxy verursacht

Der n8n-Editor hält eine langlebige Push-Verbindung zum Backend offen, damit der Ausführungsfortschritt auf dem Canvas angezeigt werden kann. Standardmäßig ist diese Verbindung ein WebSocket. N8N_PUSH_BACKEND aktiviert ihn. Der Standardwert ist websocket. Ein WebSocket beginnt als gewöhnliche HTTP-Anfrage mit den Headern Connection: Upgrade und Upgrade: websocket. Der Server antwortet mit 101 Switching Protocols. Danach verwenden beide Seiten denselben TCP-Socket in beide Richtungen.

Zwei Ursachen können das verhindern. Beide liegen im Proxy und nicht in n8n. Der Proxy verwendet zum Upstream HTTP/1.0 oder entfernt die Upgrade-Header. Dadurch findet kein Upgrade statt, und der Editor stellt die Verbindung dauerhaft erneut her. Oder das Upgrade ist erfolgreich, aber der Proxy schließt den Socket später, weil er inaktiv war. Ein WebSocket ohne Nachrichten sieht für den Proxy wie eine ungenutzte Verbindung aus. In beiden Fällen ist der Container funktionsfähig. Das Banner zeigt nur an, dass der Browser seinen Kanal verloren hat.

Bestätigen Sie dies im Browser, bevor Sie Änderungen vornehmen. Öffnen Sie die Entwicklertools, wechseln Sie zum Tab „Network“, filtern Sie nach WS und laden Sie den Editor neu. Die Push-Anfrage sollte 101 Switching Protocols erreichen und geöffnet bleiben. Eine Push-Anfrage, die einen gewöhnlichen Statuscode zurückgibt, oder eine Anfrage, die alle paar Sekunden erneut erscheint, weist auf den Proxy hin.

Die nginx-Einstellungen, die die Verbindung des Editors aufrechterhalten

nginx leitet ein Upgrade nicht weiter, wenn Sie es nicht ausdrücklich konfigurieren. proxy_pass verwendet standardmäßig HTTP/1.0 für das Backend. Connection und Upgrade sind Hop-by-Hop-Header, die nginx beim Weiterleiten entfernt. Sie müssen beide wieder gesetzt werden. Der Block map gehört in den Kontext http, nicht in server. Falls der restliche Server-Block weiter unten ungewohnt ist, erklärt die schrittweise Erläuterung eines nginx-Server-Blocks, welche Funktion jede Direktive hat.

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

server {
    listen 443 ssl;
    http2 on;
    server_name n8n.example.com;

    location / {
        proxy_pass http://127.0.0.1:5678;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 3600s;
        proxy_send_timeout 3600s;
        proxy_buffering off;
    }
}

proxy_read_timeout ist die Zeile, die häufig fehlt. Der Standardwert beträgt 60 Sekunden. Er gilt auch für eine aktualisierte WebSocket-Verbindung. Ein Editor-Tab, der in einer nicht aktiven Instanz geöffnet bleibt, verliert seine Verbindung daher etwa eine Minute nach der letzten darüber übertragenen Nachricht. Durch eine Erhöhung dieses Werts verschwindet der Hinweis, der beim Zurückkehren zu einem zuvor geöffneten Tab angezeigt wird.

sudo nginx -t && sudo systemctl reload nginx
sudo nginx -T | grep -iE 'proxy_http_version|upgrade|proxy_read_timeout'

nginx -T gibt die vollständige aktive Konfiguration aus, nicht nur eine einzelne Datei. Damit können Sie prüfen, ob Ihre Änderung tatsächlich geladen wurde. Wenn keine von include gelesene Datei die entsprechende Zeile enthält, wirkt eine korrekte Änderung scheinbar nicht.

Teilen Sie n8n anschließend mit, dass es sich hinter einem Proxy befindet, da n8n anhand dieser Werte URLs erstellt.

environment:
  - N8N_HOST=n8n.example.com
  - N8N_PROTOCOL=https
  - N8N_PORT=5678
  - N8N_PROXY_HOPS=1
  - N8N_WEBHOOK_URL=https://n8n.example.com/

N8N_PROXY_HOPS ist standardmäßig auf 0 gesetzt. Dadurch behandelt n8n die Adresse der verbindenden Gegenstelle als Client-Adresse und ignoriert X-Forwarded-For. Setzen Sie den Wert auf die Anzahl der Proxys vor dem Container. Im August 2026 ist N8N_WEBHOOK_URL die aktuelle Bezeichnung. Der ältere Name WEBHOOK_URL funktioniert weiterhin, gibt beim Start jedoch eine Warnung zur bevorstehenden Entfernung aus.

Traefik leitet WebSocket-Verbindungen weiter, beendet sie aber durch ein Timeout

Traefik leitet ein WebSocket-Upgrade ohne Middleware und zusätzliche Labels weiter. Ein Traefik-Benutzer, der dieses Banner sieht, stößt daher normalerweise auf ein Timeout und nicht auf einen fehlenden Header. Die relevanten Einstellungen befinden sich am entryPoint. Stand August 2026 verwendet Traefik v3 für idleTimeout standardmäßig 180 Sekunden und für readTimeout standardmäßig 60 Sekunden.

entryPoints:
  websecure:
    address: ":443"
    transport:
      respondingTimeouts:
        readTimeout: 0
        idleTimeout: 3600s

Caddy verarbeitet das Upgrade in reverse_proxy automatisch und benötigt dafür keine Direktive. Wenn Sie den Proxy überhaupt nicht ändern können, weil er von einer anderen Person verwaltet wird, stellen Sie den Push-Kanal mit N8N_PUSH_BACKEND=sse um. SSE (Server-Sent Events) ist eine normale HTTP-Antwort, die offen gehalten wird. Sie funktioniert daher auch mit einem Proxy, der Upgrades ablehnt. Ein aggressives Idle-Timeout beendet die Verbindung jedoch weiterhin. Die Auswahl des Proxys ist eine separate Entscheidung. Der Vergleich von nginx, Caddy und Traefik erläutert, welchen Betriebsaufwand die einzelnen Lösungen verursachen.

Wenn der Container tatsächlich neu gestartet wird

Wenn RestartCount ansteigt, schlägt der Container fehl und Docker startet ihn erneut. Ordnen Sie die Zeitstempel im Log den einzelnen Neustarts zu und prüfen Sie, was unmittelbar davor passiert ist. Fast alle Fälle lassen sich auf vier Ursachen zurückführen: ein Konfigurationsfehler, der den Start verhindert, eine Datenbank, die n8n nicht erreichen kann, ein Absturz nach dem Start und eine Beendigung wegen Speichermangels.

Beginnen Sie mit dem Volume, da Berechtigungsprobleme oft unauffällig bleiben. Das offizielle Image wird unter dem nicht privilegierten Benutzer node ausgeführt und speichert seine Daten unter /home/node/.n8n. Ein von root erstelltes Bind-Mount ist für diesen Benutzer nicht beschreibbar. Der Prozess wird daher bei jedem Start beendet, während die Restart-Policy den Fehler hinter einer Endlosschleife verbirgt.

docker compose config
docker run --rm -it --entrypoint sh docker.n8n.io/n8nio/n8n -c 'id'
docker exec n8n ls -ld /home/node/.n8n

Ein Named Volume vermeidet das Problem vollständig, da Docker es mit den richtigen Besitzrechten erstellt. Wenn Sie ein Bind-Mount benötigen, ändern Sie den Besitzer des Host-Verzeichnisses mit chown auf die numerische Benutzer-ID, die der erste Befehl ausgegeben hat. Die Zuordnung von Besitzrechten zwischen Host und Container sollten Sie einmal verstehen. Die Erläuterung zu PUID und PGID beschreibt, wie diese Images bestimmen, welcher Benutzer Dateien schreibt.

Der Out-of-Memory-Kill, der wie ein Absturz aussieht

Über einem n8n-Prozess gibt es zwei getrennte Speichergrenzen, die sich unterschiedlich auswirken. Die Begrenzung der Container-Control-Group wird vom Kernel durchgesetzt: Wird sie überschritten, beendet der Kernel den Prozess sofort. Der Prozess kann dann nichts mehr schreiben, und OOMKilled liefert true. Die V8-Heap-Grenze wird innerhalb von Node.js durchgesetzt: Wird sie überschritten, wirft Node einen Heap-Fehler mit Stacktrace und beendet sich selbst. Daher liefert OOMKilled false. Im Browser sehen beide Fälle gleich aus. In docker inspect unterscheiden sie sich nur in einem Feld.

Setzen Sie die Node-Heap-Grenze unterhalb des Container-Limits. Wenn die Heap-Grenze höher als das Container-Limit ist, reserviert V8 weiterhin Speicher, obwohl der Kernel bereits eingreifen würde. Der Garbage Collector erreicht dann seine eigene Grenze nicht. Sie erhalten immer den härteren Fehler, ohne auswertbares Log.

services:
  n8n:
    image: docker.n8n.io/n8nio/n8n
    restart: unless-stopped
    environment:
      - NODE_OPTIONS=--max-old-space-size=<MiB, below the container limit>
    deploy:
      resources:
        limits:
          memory: <your container limit>

Wählen Sie beide Werte anhand der tatsächlich auf Ihrem VPS verfügbaren Ressourcen. Lassen Sie dabei Speicher für die Datenbank, den Proxy und das Betriebssystem frei. docker stats --no-stream gibt die aktuelle Nutzung zusammen mit dem geltenden Limit aus. Damit können Sie prüfen, ob Docker das von Ihnen gesetzte Limit tatsächlich übernommen hat. So werden Speicherlimits in Compose angewendet erläutert, welcher Schlüssel gewinnt, wenn mehrere Schlüssel gesetzt sind.

Ausführungsdaten wachsen unbemerkt

Eine einzelne Ausführung enthält während des Laufs die Ausgabe jedes Nodes. n8n speichert diese Daten anschließend. Daraus folgen zwei Konsequenzen. Der maximale Speicherbedarf eines Laufs wird durch den größten Datenstapel bestimmt, den Sie durch den Workflow leiten. Ein Workflow, der zehntausend Zeilen auf einmal verarbeitet, ist daher ein anderes Programm als derselbe Workflow mit jeweils zweihundert Zeilen. Außerdem wächst die gespeicherte Kopie weiter, bis sie gelöscht wird.

Das Pruning löst das zweite Problem. Im August 2026 sind die Standardwerte: Pruning ist aktiviert, EXECUTIONS_DATA_MAX_AGE ist auf 336 Stunden (14 Tage) und EXECUTIONS_DATA_PRUNE_MAX_COUNT auf 10000 gesetzt. Diese Werte sind für einen kleinen VPS mit SQLite großzügig bemessen. Dort enthält eine Datei sämtliche Daten, und derselbe Prozess, der den Editor bereitstellt, muss sie lesen und schreiben.

environment:
  - EXECUTIONS_DATA_PRUNE=true
  - EXECUTIONS_DATA_MAX_AGE=72
  - EXECUTIONS_DATA_PRUNE_MAX_COUNT=1000
  - EXECUTIONS_DATA_SAVE_ON_SUCCESS=none
  - EXECUTIONS_DATA_SAVE_MANUAL_EXECUTIONS=false

EXECUTIONS_DATA_SAVE_ON_SUCCESS=none ist die aggressive Einstellung. Fehlgeschlagene Ausführungen bleiben zur Fehlersuche erhalten, erfolgreiche werden verworfen. Legen Sie diese Einstellung bewusst fest. Wenn ein Workflow falsche Ergebnisse erzeugt, ohne einen Fehler auszulösen, gibt es anschließend nichts mehr zu prüfen. Beim Pruning werden die Zeilen außerdem zunächst als gelöscht markiert und erst bei einem späteren Durchlauf entfernt. SQLite verwendet freigegebene Seiten wieder, statt sie an das Betriebssystem zurückzugeben. Die Datei auf dem Datenträger wird daher nicht sofort kleiner, wenn Sie die Einstellung ändern.

Wenn Sie den Spitzenverbrauch statt der gespeicherten Gesamtmenge reduzieren möchten, übertragen Sie pro Ausführung weniger Daten. Teilen Sie große Jobs in Sub-Workflows auf, die kleine Ergebnisse an den übergeordneten Workflow zurückgeben. Verwenden Sie für die Stapelverarbeitung den Node Loop Over Items. Halten Sie vollständige Datensätze aus dem Code-Node heraus.

Binärdaten sollten nicht den Arbeitsspeicher belasten

N8N_DEFAULT_BINARY_DATA_MODE ist standardmäßig auf default gesetzt. Dadurch bleiben Binärdaten im Speicher der laufenden Ausführung. Jede Datei, die ein Node herunterlädt, und jede Kopie, die an den nächsten Node übergeben wird, bleibt dort, bis der Lauf endet. Ein Workflow, der einige große Anhänge abruft, kann den Prozess über ein Limit bringen, das bei gewöhnlicher JSON-Verarbeitung nie erreicht wird. Deshalb tritt der Absturz bei einem bestimmten Workflow auf und nicht nach einer bestimmten Laufzeit.

environment:
  - N8N_DEFAULT_BINARY_DATA_MODE=filesystem

Mit filesystem werden Binärdaten unter N8N_BINARY_DATA_STORAGE_PATH gespeichert. Dieses Verzeichnis liegt standardmäßig im n8n-Benutzerordner und damit auf demselben Volume wie die übrigen Daten. Prüfen Sie vor der Umstellung, ob auf dem Volume genügend Speicherplatz verfügbar ist. N8N_PAYLOAD_SIZE_MAX legt die maximale Größe eingehender Webhook-Payloads in MiB (Mebibyte) fest und ist standardmäßig auf 16 gesetzt. Wenn Sie diesen Wert erhöhen, werden größere Requests zugelassen. Die damit verbundenen zusätzlichen Speicherkosten müssen Sie akzeptieren.

Alle anderen Prozesse und Container auf dem Host konkurrieren um denselben Arbeitsspeicher. Wenn die OOM-Kills begannen, nachdem Sie einen Datenbank-Container hinzugefügt hatten, ist der Betrieb der Datenbank in Docker oder auf dem Host der nun bestehende Zielkonflikt.

Restart-Richtlinie und Wiederanlauf nach einem Reboot

Ein Container ohne Restart-Richtlinie bleibt nach dem Beenden und nach einem Reboot des Hosts gestoppt. restart: unless-stopped startet ihn in beiden Fällen erneut, berücksichtigt aber weiterhin einen Container, den Sie manuell gestoppt haben. restart: always startet auch einen absichtlich gestoppten Container neu, sobald Docker das nächste Mal startet.

n8n stellt einen Health-Endpunkt bereit, der durch N8N_ENDPOINT_HEALTH bezeichnet wird und standardmäßig healthz lautet. Prüfen Sie ihn zunächst vom Host aus, damit Sie wissen, dass der Pfad auf Ihrer Instanz korrekt ist.

curl -fsS http://127.0.0.1:5678/healthz
docker exec n8n which wget curl
sudo systemctl is-enabled docker

Ein Healthcheck startet allein nichts neu. Compose markiert den Container als nicht funktionsfähig und beendet die Prüfung an dieser Stelle. Damit der Healthcheck eine Wirkung hat, benötigt er zusätzlich eine Restart-Richtlinie oder einen externen Watcher. Einen Healthcheck schreiben, der tatsächlich reagiert und den Stack nach einem Reboot erneut starten behandeln beide Aspekte.

Der Workflow wird nicht ausgelöst, obwohl n8n funktioniert

Dieser Workflow erzeugt kein Banner und startet nichts neu. Der Container läuft, der Editor funktioniert, und der erwartete Lauf fehlt in der Ausführungsliste. In den meisten Fällen ist eine von vier Ursachen verantwortlich.

• Der Workflow ist nicht aktiv. Ein Schedule Trigger wird nur im Produktionspfad ausgeführt. Ein Test im Canvas plant daher nichts.
• Die Zeitzone ist nicht Ihre lokale Zeitzone. GENERIC_TIMEZONE verwendet standardmäßig America/New_York. Ein für 09:00 eingestellter Zeitplan wird daher in dieser Zeitzone um 09:00 ausgelöst, bis Sie GENERIC_TIMEZONE und TZ auf Ihre eigene Zeitzone setzen.
• Ausfallzeiten werden nicht nachträglich ausgeführt. Trigger werden beim Start von n8n registriert. Ein Zeitplan, der während eines Neustarts des Containers fällig war, wird daher nicht verspätet ausgeführt. Der nächste Lauf erfolgt zum nächsten Fälligkeitszeitpunkt nach dem Start.
• Der Workflow wurde automatisch deaktiviert. N8N_WORKFLOW_AUTODEACTIVATION_ENABLED ist standardmäßig deaktiviert. Wenn die Option aktiviert ist, wird ein Workflow, der wiederholt abstürzt, aus der Veröffentlichung genommen. Danach sieht er genauso aus wie ein Workflow, den niemand aktiviert hat.

Öffnen Sie die Ausführungsliste und filtern Sie nach diesem Workflow. Ein fehlgeschlagener Eintrag weist auf ein Problem im Workflow hin. Ist er mit einem 429-Fehler bei einem anderen Dienst fehlgeschlagen, den Sie auf demselben Server betreiben, gehört das Limit zu diesem Dienst und nicht zu n8n. Die Anleitung zu 429-Fehlern bei SearXNG zeigt, wie Sie den eigenen Rate Limiter von den Suchmaschinen unterscheiden, die die IP-Adresse Ihres Servers blockieren. Gibt es überhaupt keinen Eintrag, liegt ein Trigger-Problem vor. Die vier genannten Ursachen sind dann die richtige Stelle für die weitere Prüfung.

Was Sie zuerst ändern sollten

1. Lesen Sie STATUS, RestartCount und OOMKilled im eigenen Container, bevor Sie eine Datei bearbeiten.
2. Wenn der Container nie beendet wurde, korrigieren Sie die Upgrade-Header des Proxys und das Idle-Timeout.
3. Wenn OOMKilled den Wert true hat, legen Sie bewusst ein Container-Limit fest, setzen Sie die Node-Heap-Obergrenze darunter und stellen Sie Binärdaten auf filesystem um.
4. Wenn nichts ausgelöst wurde, prüfen Sie, ob der Workflow aktiv ist und die Zeitzone der Instanz Ihrer Zeitzone entspricht.

Der größte Teil davon ist eine einmalige Konfiguration, die Sie nach einer funktionierenden Installation nicht weiter ändern müssen. Wenn Sie diese Installation noch zusammenstellen, ist die Anleitung zu n8n mit Docker und HTTPS die Grundlage für diese Einstellungen.

FAQ

Warum zeigt der n8n-Editor das Banner für eine verlorene Verbindung, obwohl der Container läuft?

Der Editor hält eine WebSocket-Verbindung offen, um den Ausführungsfortschritt zu übertragen. Wenn Ihr Reverse Proxy die Header Connection: Upgrade und Upgrade: websocket nicht weiterleitet oder zum Upstream keine HTTP/1.1-Verbindung verwendet, wird das Upgrade nicht abgeschlossen. Der Browser verbindet sich dann dauerhaft neu, während n8n weiterhin fehlerfrei läuft. In nginx benötigen Sie proxy_http_version 1.1 sowie beide proxy_set_header-Zeilen. Außerdem benötigen Sie ein proxy_read_timeout, das länger als die standardmäßigen 60 Sekunden ist, damit ein inaktiver Tab nicht getrennt wird. Prüfen Sie die aktive Konfiguration mit sudo nginx -T und nicht mit der bearbeiteten Datei.

Wie unterscheide ich eine Beendigung wegen Speichermangels von einem normalen Absturz?

Führen Sie docker inspect n8n | grep -iE 'OOMKilled|ExitCode|RestartCount' aus und prüfen Sie das Flag OOMKilled. Der Wert True bedeutet, dass der Kernel den Prozess beendet hat, weil dieser ein Speicherlimit überschritten hat. Im Container-Log finden Sie dann keine verwertbaren Informationen, weil der Prozess keine Gelegenheit zum Schreiben hatte. Der Wert False zusammen mit einem Heap-Fehler und einem Stacktrace am Ende von docker logs bedeutet, dass Node.js die eigene V8-Heap-Grenze erreicht und sich selbst beendet hat. Setzen Sie NODE_OPTIONS=--max-old-space-size unterhalb des Container-Limits, damit der zweite Fehler auftritt. Nur dieser hinterlässt entsprechende Hinweise.

Gibt das Bereinigen von Ausführungsdaten sofort Speicherplatz frei?

Nein. EXECUTIONS_DATA_PRUNE markiert alte Ausführungen zur Löschung. Ein späterer Durchlauf entfernt sie gemäß dem in EXECUTIONS_DATA_PRUNE_HARD_DELETE_INTERVAL festgelegten Zeitplan. Bei SQLite verwendet die Datei freigegebene Seiten außerdem wieder, statt sie an das Dateisystem zurückzugeben. Daher bleibt die Größe auf dem Datenträger noch eine Weile unverändert, nachdem die Datensätze gelöscht wurden. Setzen Sie EXECUTIONS_DATA_MAX_AGE und EXECUTIONS_DATA_PRUNE_MAX_COUNT auf Werte, die zu Ihrem System passen. Prüfen Sie die Größe am folgenden Tag erneut und nicht sofort.

Warum wurde mein geplantes Workflow nicht ausgeführt, während n8n neu gestartet wurde?

n8n registriert Trigger beim Start des Prozesses. Zeitpläne, die während des Ausfalls fällig waren, werden nicht nachträglich ausgeführt. Eine Neustartschleife führt daher nicht zu einer großen Zahl nachgeholter Ausführungen. Die nächste Ausführung erfolgt zum nächsten Fälligkeitszeitpunkt nach dem Start. Wenn Ausführungen nicht ausfallen dürfen, lassen Sie den Workflow von einem externen Aufrufer über einen Webhook starten. Die Wiederholungslogik liegt dann außerhalb von n8n.

Startet ein Healthcheck n8n neu, wenn der Dienst nicht mehr antwortet?

Nicht selbstständig. Ein Compose-Healthcheck markiert den Container lediglich als fehlerfrei oder fehlerhaft. Für den Neustart ist die Restart-Richtlinie zuständig. restart: unless-stopped startet den Container nach dessen Beendigung erneut. Die Richtlinie startet ihn auch nach einem Neustart des Hosts erneut, sofern der Docker-Dienst aktiviert ist. Bestätigen Sie das mit sudo systemctl is-enabled docker. Wenn Sie gezielt auf den Status unhealthy reagieren möchten, benötigen Sie außerhalb von Docker einen Überwachungsdienst. Dieser liest den Status und startet den Dienst neu.