Ausführung hängt: Stuck Executions finden, Timeouts konfigurieren

In n8n siehst du eine Ausführung, die einfach nicht fertig wird. Der Status bleibt auf „Running“ oder „Waiting“ stehen, obwohl der Workflow längst hätte durchlaufen sein müssen. Genau das nennt man eine hängende oder „stuck“ Execution, und sie ist mehr als nur ein kosmetisches Problem: In der Standardeinstellung kennt n8n laut der offiziellen Referenz zu Execution-Variablen gar kein Zeitlimit, EXECUTIONS_TIMEOUT steht per Default auf -1. Ohne eigene Konfiguration kann eine Ausführung also theoretisch endlos weiterlaufen und dabei Ressourcen, Worker-Slots und im Queue-Modus ganze Warteschlangen blockieren.

Dieser Artikel zeigt dir, woran du hängende Executions erkennst, welche Ursachen typischerweise dahinterstecken und wie du mit EXECUTIONS_TIMEOUT und EXECUTIONS_TIMEOUT_MAX ein sauberes Zeitlimit setzt, das zu deiner Instanz passt. Stand: Juli 2026.

Woran erkennst du hängende Executions?

• Im Reiter „Executions“ bleibt der Status dauerhaft auf „Running“ oder „Waiting“ stehen, obwohl vergleichbare Läufe normalerweise in Sekunden oder wenigen Minuten fertig sind.
• Die Laufzeitanzeige wächst immer weiter, ohne dass neue Log-Einträge oder Knotenwechsel sichtbar werden.
• Im Queue-Modus sammeln sich neue Executions in der Warteschlange, weil ein Worker durch die hängende Ausführung blockiert ist und laut Konfiguration über N8N_CONCURRENCY_PRODUCTION_LIMIT keine weiteren Läufe parallel starten darf.
• Der Server verbraucht spürbar mehr Arbeitsspeicher oder CPU, ohne dass sich das mit der aktuellen Auslastung erklären lässt.

Ein einzelner hängender Lauf wirkt zunächst harmlos. In der Praxis reicht aber schon eine Handvoll solcher Ausführungen, um eine ganze n8n-Instanz spürbar zu verlangsamen, gerade wenn mehrere Workflows sich denselben Worker-Pool teilen.

Typische Ursachen für hängende Ausführungen

• Kein Timeout gesetzt: Ohne eigene EXECUTIONS_TIMEOUT-Konfiguration greift kein automatisches Limit, ein einzelner fehlerhafter Node kann den kompletten Lauf offen halten.
• Externe Aufrufe ohne eigenes Timeout: Ein HTTP Request Node, der auf eine sehr langsame oder nicht antwortende API wartet, hängt so lange, bis die Gegenstelle reagiert oder n8n selbst eingreift.
• Falsch konfigurierte Wait-Nodes: Ein Wait-Node, der auf ein externes Ereignis wartet, das nie eintritt, hält die Ausführung dauerhaft im Status „Waiting“.
• Hängende Sub-Workflows: Ruft dein Hauptworkflow einen Unterworkflow auf, überträgt sich dessen Hänger direkt auf den übergeordneten Lauf.
• Probleme im Queue-Modus: Ist die Verbindung zwischen Hauptprozess und Worker gestört, etwa durch einen instabilen Redis-Zugang, bleiben Executions im Zustand „Running“, ohne dass der Worker sie tatsächlich noch bearbeitet.

EXECUTIONS_TIMEOUT und EXECUTIONS_TIMEOUT_MAX richtig setzen

Für ein verlässliches Zeitlimit sind laut der Konfigurationsanleitung zu Workflow-Timeouts zwei Umgebungsvariablen entscheidend:

• EXECUTIONS_TIMEOUT: Setzt das Standard-Zeitlimit in Sekunden, das für alle Workflows gilt, sofern kein individuelles Limit hinterlegt ist. Der Default ist -1, also deaktiviert. Ein Wert von 3600 begrenzt jeden Lauf auf eine Stunde.
• EXECUTIONS_TIMEOUT_MAX: Definiert die absolute Obergrenze in Sekunden, die auch dann gilt, wenn ein einzelner Workflow ein höheres eigenes Timeout gesetzt hat. Der Standardwert liegt laut Referenz bei 3600 Sekunden.

Wichtig für das Verständnis, wie das Timeout technisch greift: Läuft der Workflow im Hauptprozess, erfolgt laut Dokumentation ein weicher Timeout, der erst nach Abschluss des gerade aktiven Knotens wirkt. Läuft die Ausführung dagegen in einem separaten Prozess, etwa im Queue-Modus auf einem Worker, versucht n8n zunächst ebenfalls einen weichen Abbruch und erzwingt danach einen harten Abbruch. Für dich bedeutet das: Ein Timeout ist kein sofortiger Reißschwung, sondern ein gestaffelter Mechanismus, der laufende Arbeit möglichst sauber beendet, bevor er hart eingreift.

Einzelne Workflows können in ihren Workflow-Einstellungen ein eigenes, niedrigeres Timeout hinterlegen. Nach oben begrenzt bleibt das aber immer durch EXECUTIONS_TIMEOUT_MAX, sodass ein einzelner Workflow das globale Limit nicht überschreiten kann. Damit behältst du die Kontrolle über die maximale Laufzeit, ohne dass jeder einzelne Workflow individuell abgesichert werden muss.

Ausführungsdaten aufräumen, damit die Datenbank schlank bleibt

Neben dem reinen Zeitlimit lohnt sich ein Blick auf die Aufbewahrung von Ausführungsdaten, denn eine überfüllte Datenbank erschwert auch die Diagnose hängender Läufe. n8n räumt Ausführungsdaten laut Referenz automatisch auf:

• EXECUTIONS_DATA_PRUNE (Standard: aktiviert) steuert, ob abgeschlossene Ausführungen überhaupt automatisch gelöscht werden.
• EXECUTIONS_DATA_MAX_AGE legt fest, nach wie vielen Stunden alte Ausführungen als Kandidaten für die Löschung gelten, der Standardwert entspricht 14 Tagen.
• Aktive Ausführungen mit dem Status „new“, „running“ oder „waiting“ werden von der Bereinigung ausdrücklich ausgenommen, ebenso Ausführungen, die du mit Tags oder Bewertungen versehen hast.

Diese Schutzmechanismen sind ein zweischneidiges Schwert: Sie verhindern zwar, dass eine noch laufende Ausführung versehentlich gelöscht wird, gleichzeitig bleibt eine wirklich hängende Ausführung dadurch auch dauerhaft in der Datenbank stehen, solange kein Timeout sie regulär beendet. Genau deshalb ist die Kombination aus einem sinnvollen EXECUTIONS_TIMEOUT und funktionierender Datenbereinigung wichtig, damit sich hängende Läufe nicht unbemerkt ansammeln.

Checkliste für die Praxis

• Prüfe zuerst im Executions-Reiter, welche Läufe tatsächlich seit Stunden oder Tagen auf „Running“ oder „Waiting“ stehen.
• Setze EXECUTIONS_TIMEOUT auf einen realistischen Wert für deine längsten regulären Workflows, plus einen Sicherheitspuffer.
• Setze EXECUTIONS_TIMEOUT_MAX so, dass auch besonders lange Einzelworkflows nicht unbegrenzt laufen können.
• Kontrolliere bei extern angebundenen Nodes, etwa HTTP Request oder Webhook-Wartepunkte, ob dort ein eigenes Timeout sinnvoll ergänzt werden sollte.
• Behalte im Queue-Modus zusätzlich die Verbindung zu Redis und die Auslastung deiner Worker im Blick, denn ein hängender Worker verursacht ganz andere Symptome als ein hängender einzelner Workflow.

Wenn du n8n als digitalen Mitarbeiter in deinem Unternehmen betreibst, gehört ein sauber konfiguriertes Timeout zur Grundausstattung, genau wie ein Blick auf Concurrency-Limits und Datenbereinigung. Wer diese Stellschrauben einmal richtig setzt, muss sich um hängende Ausführungen in der Regel nicht mehr manuell kümmern. Wenn du dabei Unterstützung brauchst oder deine n8n-Instanz grundsätzlich stabiler aufstellen willst, unterstützt dich NordFlux beim Aufbau und Betrieb von n8n-Workflows.

Häufige Fragen

Was bedeutet der Status „Waiting“ bei einer n8n-Execution?

„Waiting“ zeigt an, dass die Ausführung an einem Punkt im Workflow auf ein externes Ereignis wartet, etwa eine Antwort von einem Wait-Node oder einen ausstehenden Webhook-Aufruf. Bleibt dieser Status über die erwartete Laufzeit hinaus dauerhaft bestehen, deutet das auf ein Ereignis hin, das nie eintrifft, und die Ausführung hängt effektiv fest, bis ein Timeout sie beendet.

Welchen Wert sollte ich für EXECUTIONS_TIMEOUT setzen?

Es gibt keinen pauschal richtigen Wert, er hängt von deinen längsten regulären Workflows ab. Als Ausgangspunkt hilft es, die normale Laufzeit deiner aufwendigsten Automatisierung zu messen und großzügig, etwa um das Zwei- bis Dreifache, aufzurunden. So bleibt genug Puffer für normale Schwankungen, während wirklich hängende Läufe trotzdem zuverlässig beendet werden.

Beendet EXECUTIONS_TIMEOUT eine Ausführung sofort?

Nein, laut n8n-Dokumentation erfolgt zunächst ein weicher Abbruch. Im Hauptprozess wartet n8n, bis der aktuell laufende Knoten fertig ist, in separaten Prozessen wird nach einem weichen Versuch zusätzlich ein harter Abbruch nach kurzer Wartezeit erzwungen. Der Übergang läuft also gestaffelt und nicht abrupt.

Kann ein einzelner Workflow ein höheres Timeout haben als EXECUTIONS_TIMEOUT_MAX erlaubt?

Nein. EXECUTIONS_TIMEOUT_MAX definiert die absolute Obergrenze für die gesamte Instanz. Auch wenn ein Workflow in seinen eigenen Einstellungen ein höheres individuelles Timeout hinterlegt hat, wird dieser Wert durch EXECUTIONS_TIMEOUT_MAX gekappt, sodass kein Workflow das globale Limit überschreiten kann.

Werden hängende Executions automatisch aus der Datenbank gelöscht?

Nicht, solange sie aktiv sind. n8n schließt Ausführungen mit dem Status „new“, „running“ oder „waiting“ ausdrücklich von der automatischen Bereinigung über EXECUTIONS_DATA_PRUNE aus. Eine wirklich hängende Ausführung bleibt deshalb bestehen, bis entweder ein konfiguriertes Timeout sie beendet oder du sie manuell abbrichst.