n8n geht offline: 4 Ursachen auf dem VPS prüfen

Warum n8n offline geht: vier Fehler, ein Symptom

„n8n geht offline“ beschreibt vier unterschiedliche Fehler. Für jeden Fehler ist eine andere Lösung erforderlich. Der Editor zeigt ein Banner ü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 mit dem Prozess ist überhaupt nichts falsch, und ein aktiver Workflow wird einfach nie ausgelöst. Wenn Sie die falsche Einstellung ändern, verbringen Sie ein 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 und hinter einem Reverse Proxy, der TLS (Transport Layer Security) beendet. Jede dieser Schichten 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 Ihr eigenes System ausgibt. Vergleichen Sie sie nicht mit Zahlen aus einem Forenbeitrag. Die hier relevanten Werte beschreiben Ihren Server, nicht den 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 schon lange vor dem Erscheinen des Banners aktiv war, ist n8n nicht ausgefallen. 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ährenddessen an, liegt eine Neustartschleife vor. Die Logzeilen unmittelbar vor jedem Neustart enthalten den Grund.

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

ExitCode enthält den Exit-Code, mit dem Ihr Container zuletzt beendet wurde. Sie müssen nicht auswendig wissen, was jeder Code bedeutet. Lesen Sie den Wert Ihres Containers ab und anschließend das Ende von docker logs mit demselben Zeitstempel. Die letzten Logzeilen und das Out-of-Memory-Flag zeigen zusammen, was passiert ist. Jeder einzelne Wert kann jedoch irreführend sein.

docker stats zeigt die aktuelle Speichernutzung neben dem geltenden Limit. Lassen Sie den Befehl in einem zweiten Terminal weiterlaufen, lösen Sie den fehlschlagenden Workflow aus 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 wählt diesen Verbindungstyp aus. Der Standardwert ist websocket. Ein WebSocket beginnt als normale 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 diese Verbindung unterbrechen. 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 ständig erneut her. Oder das Upgrade gelingt, aber der Proxy schließt den Socket später wegen Inaktivität. Ein WebSocket ohne Nachrichten sieht für den Proxy wie eine inaktive Verbindung aus. In beiden Fällen ist der Container funktionsfähig. Das Banner zeigt an, dass der Browser seinen Kanal verloren hat.

Prüfen 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. Wenn die Push-Anfrage einen normalen Statuscode zurückgibt oder alle paar Sekunden erneut erscheint, liegt die Ursache wahrscheinlich im Proxy.

Die nginx-Einstellungen, die den Editor verbunden halten

nginx leitet ein Upgrade nicht weiter, sofern 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.

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 wird häufig vergessen. Der Standardwert beträgt 60 Sekunden. Er gilt auch für ein aktualisiertes WebSocket. Deshalb verliert ein geöffnetes Editor-Tab bei einer ruhenden Instanz etwa eine Minute nach der letzten übertragenen Nachricht die Verbindung. Ein höherer Wert verhindert die Meldung, die beim Zurückkehren zu einem 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 gesamte aktive Konfiguration aus, nicht nur eine einzelne Datei. Damit können Sie prüfen, ob Ihre Änderung tatsächlich geladen wurde. Wenn sich eine Konfiguration in einer Datei befindet, die von keiner von include eingelesenen Datei eingebunden wird, scheint eine korrekte Änderung keine Wirkung zu haben.

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

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 Verbindungsadresse als Clientadresse und ignoriert X-Forwarded-For. Setzen Sie den Wert auf die Anzahl der Proxies vor dem Container. Seit August 2026 lautet der aktuelle Name N8N_WEBHOOK_URL. Der ältere Name WEBHOOK_URL funktioniert weiterhin, gibt beim Start jedoch eine Veraltungswarnung aus.

Traefik leitet WebSockets weiter und beendet sie dann per 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 einen Timeout und nicht auf einen fehlenden Header. Die Einstellungen befinden sich am entryPoint. Stand August 2026 ist idleTimeout in Traefik v3 standardmäßig auf 180 Sekunden und readTimeout standardmäßig auf 60 Sekunden gesetzt.

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

Caddy verarbeitet das Upgrade automatisch in reverse_proxy und benötigt dafür keine Direktive. Wenn Sie den Proxy überhaupt nicht ändern können, weil er von jemand anderem verwaltet wird, wechseln Sie den Push-Kanal mit N8N_PUSH_BACKEND=sse. SSE (Server-Sent Events) ist eine normale HTTP-Antwort, die offen gehalten wird. Daher funktioniert SSE auch mit einem Proxy, der Upgrades ablehnt. Ein aggressiver Idle-Timeout beendet die Verbindung jedoch weiterhin. Die Auswahl des Proxys ist eine separate Entscheidung. Der Vergleich von nginx, Caddy und Traefik beschreibt, welcher Betriebsaufwand bei den einzelnen Lösungen anfällt.

Wenn der Container tatsächlich neu startet

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 oder eine Beendigung wegen Speichermangels.

Beginnen Sie mit dem Volume, da Berechtigungen oft unbemerkt die Ursache sind. Das offizielle Image wird unter dem nicht privilegierten Benutzer node ausgeführt und speichert seine Daten in /home/node/.n8n. Ein von root erstellter Bind-Mount ist für diesen Benutzer nicht beschreibbar. Deshalb beendet sich der Prozess bei jedem Start, während die Restart-Richtlinie den Fehler hinter einer Neustartschleife 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 benanntes Volume vermeidet das Problem vollständig, da Docker es mit den richtigen Besitzrechten erstellt. Wenn Sie einen Bind-Mount benötigen, chown das Host-Verzeichnis auf die numerische Benutzer-ID, die der erste Befehl ausgegeben hat. Die Zuordnung von Besitzrechten zwischen Host und Container sollten Sie einmal verstanden haben. Die Erläuterung zu PUID und PGID beschreibt, wie diese Images festlegen, welcher Benutzer die Dateien schreibt.

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

Für einen n8n-Prozess gibt es zwei voneinander unabhängige Speichergrenzen. Sie schlagen unterschiedlich fehl. Das Control-Group-Limit des Containers wird vom Kernel durchgesetzt: Wird es überschritten, beendet der Kernel den Prozess sofort. Der Prozess kann dann nichts mehr schreiben, und OOMKilled liefert true. Das V8-Heap-Limit wird innerhalb von Node.js durchgesetzt: Wird es überschritten, wirft Node einen Heap-Fehler mit Stacktrace und beendet sich selbst. Daher liefert OOMKilled false. Im Browser sehen beide Fälle identisch 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, allokiert V8 weiter, bis der Kernel eingreift. Der Garbage Collector erreicht dann sein eigenes Limit nicht, und Sie erhalten immer den schwerwiegenderen Fehler, ohne dass ein Log zum Lesen vorhanden ist.

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ächlichen Ressourcen Ihres VPS. Lassen Sie ausreichend Speicher für die Datenbank, den Proxy und das Betriebssystem frei. docker stats --no-stream gibt die aktuelle Nutzung neben dem geltenden Limit aus. So können Sie prüfen, ob Docker das von Ihnen gesetzte Limit übernommen hat. So werden Speicherlimits in Compose angewendet erläutert, welcher Schlüssel Vorrang hat, wenn mehrere Schlüssel gesetzt sind.

Ausführungsdaten wachsen im Hintergrund

Eine einzelne Ausführung enthält während des Laufs die Ausgabe jedes Knotens. n8n speichert diese Daten anschließend. Daraus ergeben sich zwei Konsequenzen. Der Spitzenverbrauch des Arbeitsspeichers eines Laufs wird durch den größten Datenstapel bestimmt, den Sie durch den Workflow leiten. Ein Workflow, der 10000 Zeilen gleichzeitig verarbeitet, ist daher ein anderes Programm als derselbe Workflow mit 200 Zeilen pro Durchlauf. Außerdem wächst die gespeicherte Kopie weiter, bis sie gelöscht wird.

Das Bereinigen löst das zweite Problem. Stand August 2026 sind die Standardwerte: Bereinigung aktiviert, EXECUTIONS_DATA_MAX_AGE auf 336 Stunden (14 Tage) und EXECUTIONS_DATA_PRUNE_MAX_COUNT auf 10000 gesetzt. Das sind großzügige Werte für einen kleinen VPS mit SQLite. 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. Sie behält fehlgeschlagene Ausführungen zur Fehlersuche und verwirft erfolgreiche Ausführungen. Legen Sie diese Einstellung bewusst fest. Wenn ein Workflow eine falsche Ausgabe erzeugt, ohne einen Fehler zu melden, können Sie sonst nichts mehr untersuchen. Beim Bereinigen 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. Daher wird die Datei auf dem Datenträger nicht sofort kleiner, wenn Sie die Einstellung ändern.

Um den Spitzenverbrauch statt der gespeicherten Gesamtmenge zu reduzieren, verschieben Sie pro Ausführung weniger Daten. Teilen Sie große Aufträge in Sub-Workflows auf, die kleine Ergebnisse an den übergeordneten Workflow zurückgeben. Verwenden Sie den Knoten Loop Over Items für die Stapelverarbeitung. Halten Sie vollständige Datensätze aus dem Code-Knoten heraus.

Binärdateien sollten nicht durch den Arbeitsspeicher laufen

N8N_DEFAULT_BINARY_DATA_MODE ist standardmäßig auf default gesetzt. Dadurch bleiben Binärdaten im Arbeitsspeicher 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 hinausbringen, das bei gewöhnlicher JSON-Verarbeitung nie erreicht wird. Deshalb tritt der Absturz bei einem bestimmten Workflow und nicht nach einer bestimmten Laufzeit auf.

environment:
  - N8N_DEFAULT_BINARY_DATA_MODE=filesystem

Mit filesystem werden Binärdaten unter N8N_BINARY_DATA_STORAGE_PATH gespeichert. Dieser Pfad liegt standardmäßig im n8n-Benutzerverzeichnis und damit auf demselben Volume wie die übrigen Daten. Prüfen Sie vor der Umstellung, ob auf dem Volume ausreichend 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, können größere Anfragen angenommen werden. Die dadurch entstehenden zusätzlichen Speicheranforderungen müssen Sie einplanen.

Alle anderen Dienste auf dem System konkurrieren um denselben Arbeitsspeicher. Wenn die OOM-Kills begonnen haben, nachdem Sie einen Datenbank-Container hinzugefügt haben, ist der Betrieb der Datenbank in Docker oder auf dem Host der Kompromiss, für den Sie sich nun entscheiden.

Neustart-Richtlinie und Wiederanlauf nach einem Reboot

Ein Container ohne Neustart-Richtlinie bleibt beendet, sobald er beendet wurde, und auch nach einem Reboot des Hosts. restart: unless-stopped startet ihn in beiden Fällen erneut, berücksichtigt dabei aber einen Container, den Sie manuell gestoppt haben. restart: always startet auch einen Container erneut, den Sie absichtlich gestoppt haben, sobald Docker anschließend wieder gestartet wird.

n8n stellt einen Health-Endpunkt bereit, dessen Pfad durch N8N_ENDPOINT_HEALTH festgelegt 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 gesund und beendet die Prüfung an diesem Punkt. Der Healthcheck benötigt daher eine Neustart-Richtlinie oder einen externen Watcher daneben, damit er eine Wirkung hat. Einen tatsächlich wirksamen Healthcheck schreiben und den Stack nach einem Reboot erneut starten behandeln beide Aspekte.

Der Workflow wird nie ausgeführt, obwohl n8n funktioniert

Dieser Fall erzeugt weder ein Banner noch einen Neustart. Der Container läuft, der Editor funktioniert, und der erwartete Lauf fehlt in der Ausführungsliste. Meistens ist eine von vier Ursachen dafür verantwortlich.

• Der Workflow ist nicht aktiv. Ein Schedule Trigger wird nur im Produktionspfad ausgeführt. Ein Test im Canvas plant daher keine Ausführung.
• Die Zeitzone ist nicht Ihre eigene. GENERIC_TIMEZONE verwendet standardmäßig America/New_York. Ein Zeitplan für 09:00 wird daher in dieser Zeitzone um 09:00 ausgeführt, bis Sie GENERIC_TIMEZONE und TZ auf Ihre eigene Zeitzone setzen.
• Ausfallzeiten werden nicht nachträglich aufgeholt. Trigger werden beim Start von n8n registriert. Ein Zeitplan, der während des 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 Funktion 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 Workflow-Problem hin. Gibt es überhaupt keinen Eintrag, liegt das Problem beim Trigger. Die vier oben genannten Ursachen sind dann die ersten Prüfstellen.

Was Sie zuerst ändern sollten

1. Lesen Sie STATUS, RestartCount und OOMKilled im eigenen Container, bevor Sie eine Datei bearbeiten.
2. Wenn der Container nicht beendet wurde, korrigieren Sie zunächst die Upgrade-Header des Proxys und das Inaktivitäts-Timeout.
3. Wenn OOMKilled zutrifft, 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 ob die Zeitzone der Instanz Ihrer Zeitzone entspricht.

Den größten Teil dieser Konfiguration legen Sie einmalig auf einer funktionierenden Installation fest. Wenn Sie die Installation noch einrichten, ist die Anleitung n8n in Docker mit HTTPS die Grundlage für diese Einstellungen.

FAQ

Warum zeigt der n8n-Editor das Banner für eine verlorene Verbindung an, 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 upstream nicht HTTP/1.1 verwendet, wird das Upgrade nicht abgeschlossen. Der Browser versucht dann dauerhaft, die Verbindung wiederherzustellen, 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 muss proxy_read_timeout länger als die standardmäßigen 60 Sekunden sein, 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. True bedeutet, dass der Kernel den Prozess beendet hat, weil dieser ein Speicherlimit überschritten hat. Im Container-Log steht dann keine verwertbare Information, weil der Prozess keine Gelegenheit hatte, etwas zu schreiben. 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. Dadurch tritt der zweite Fehlerfall ein, der verwertbare Hinweise hinterlässt.

Gibt das Bereinigen von Ausführungsdaten sofort Speicherplatz frei?

Nein. EXECUTIONS_DATA_PRUNE markiert alte Ausführungen zur Löschung. Ein späterer Bereinigungslauf entfernt sie gemäß dem Zeitplan aus EXECUTIONS_DATA_PRUNE_HARD_DELETE_INTERVAL. Bei SQLite verwendet die Datei freigegebene Seiten außerdem wieder, anstatt sie an das Dateisystem zurückzugeben. Deshalb bleibt die Größe auf dem Datenträger noch eine Zeit lang unverändert, nachdem die Zeilen entfernt wurden. Setzen Sie EXECUTIONS_DATA_MAX_AGE und EXECUTIONS_DATA_PRUNE_MAX_COUNT auf Werte, die für Ihr System geeignet sind. Prüfen Sie die Größe anschließend am nächsten Tag und nicht sofort erneut.

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 der Betriebsunterbrechung fällig wurden, führt n8n nicht nachträglich aus. Eine Neustartschleife führt daher nicht zu einer Reihe nachgeholter Ausführungen. Die nächste Ausführung findet zum nächsten fälligen Zeitpunkt nach dem Start statt. Wenn bestimmte Ausführungen nicht ausfallen dürfen, lassen Sie den Workflow von einem externen Aufrufer über einen Webhook starten. Die Logik für Wiederholungen liegt dann außerhalb von n8n.

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

Nicht selbstständig. Ein Compose-Healthcheck markiert den Container lediglich als healthy oder unhealthy. Für den Neustart ist die Restart Policy zuständig. restart: unless-stopped startet den Container daher neu, nachdem er beendet wurde. Das gilt auch nach einem Neustart des Hosts, sofern der Docker-Dienst aktiviert ist. Bestätigen Sie dies mit sudo systemctl is-enabled docker. Wenn Sie gezielt auf den Status unhealthy reagieren möchten, benötigen Sie einen externen Watcher außerhalb von Docker. Dieser liest den Status und startet den Dienst neu.