n8n 2.33.6: Task Runner und MCP-Ausführungen stabiler

Kurz gesagt: n8n 2.33.6 ist seit dem 7. August 2026 der aktuelle stabile Patchstand. Für Unternehmen stecken die wichtigsten betrieblichen Änderungen dieser Woche in den vorangegangenen Patches 2.33.3 und 2.33.4: Task Runner sollen sich nach Abstürzen oder blockierten Zuständen zuverlässiger erholen, und bei MCP-Tool-Aufrufen über SSE werden Ausführungsdaten erst gespeichert, wenn das Tool tatsächlich fertig ist.

Das ist keine neue Sicherheitswarnung und kein Grund für ein unkontrolliertes Sofort-Update. Relevant ist die Veröffentlichung vor allem für Self-hosted-Umgebungen mit Code Nodes, externen Task Runnern, Queue Mode oder produktiven MCP-Workflows. Diese Teams sollten den Patch in einer vergleichbaren Testumgebung prüfen und anschließend kontrolliert ausrollen.

Was ist diese Woche erschienen?

n8n hat innerhalb der stabilen 2.33-Linie mehrere Patches veröffentlicht. Die offiziellen Release Notes zu 2.33.3 datieren vom 31. Juli 2026. Es folgten 2.33.4 am 5. August, 2.33.5 am 6. August und 2.33.6 am 7. August.

Entscheidend für die Einordnung: Die parallel veröffentlichte Version 2.34.x ist auf GitHub als Vorabversion gekennzeichnet. Die höhere Versionsnummer bedeutet daher nicht, dass 2.34.x bereits der bevorzugte Produktionskanal ist. Am Veröffentlichungstag zeigt n8n den Stable-Kanal auf 2.33.6.

Warum der Task-Runner-Fix für den Betrieb wichtig ist

Task Runner führen unter anderem Code aus Code Nodes getrennt vom Hauptprozess aus. Das ist besonders bei Self-hosted-Installationen mit externer Runner-Konfiguration oder skalierter Architektur relevant. Laut den Release Notes verbessert 2.33.4 sowohl die Widerstandsfähigkeit des Task Brokers beim Ausfall eines Runners als auch die Wiederherstellung nicht mehr reagierender Runner.

Der offizielle Pull Request zum Broker-Fix beschreibt das frühere Verhalten konkret: Starb ein Runner abrupt, konnte der Broker ihn noch für eine gewisse Zeit als nutzbar behandeln. Neue Aufgaben wurden dann einem nicht erreichbaren Runner zugeordnet und endeten mit einem Timeout. Mit dem Patch sollen unerreichbare Runner keine neuen Aufgaben mehr erhalten. Bereits laufende Arbeit auf einer verlorenen Verbindung schlägt früher fehl, und eine fehlgeschlagene Zuordnung kann begrenzt gegen einen anderen Runner wiederholt werden.

Ein zweiter offizieller Pull Request zur Wiederherstellung blockierter Runner behandelt Situationen, in denen Code-Node-Ausführungen dauerhaft mit „Task request timed out after 60 seconds“ scheiterten, bis jemand die Instanz manuell neu startete. n8n ergänzt dafür Wiederanlaufversuche, die Erkennung wiederholter Annahme-Timeouts und den gezielten Neustart des betroffenen Runner-Prozesses.

Für den Geschäftsbetrieb ist das relevant, weil ein vorübergehender Runner-Fehler nicht zu einer stundenlangen Störung aller nachfolgenden Code-Node-Ausführungen werden soll. Der Patch ersetzt jedoch kein Monitoring. Der Hersteller nennt weiterhin eine mögliche Erkennungsverzögerung, wenn eine Netzwerkverbindung technisch offen wirkt, obwohl der Runner nicht mehr erreichbar ist.

Was wurde beim MCP Server Trigger korrigiert?

n8n 2.33.3 korrigiert außerdem die Speicherung von Ausführungsdaten beim MCP Server Trigger. Der zugehörige n8n-Pull-Request erklärt, dass Ausführungen bei Tool-Aufrufen über Server-Sent Events zuvor gespeichert werden konnten, bevor das Tool fertig war. Dadurch erschien eine Ausführung früh in der Liste, während für den Tool-Unterknoten noch keine Ausgabedaten erfasst waren.

Nach dem Fix soll die Speicherung erst nach Abschluss des Tool-Aufrufs erfolgen. Das verbessert die Nachvollziehbarkeit bei Fehlersuche, Audit und fachlicher Kontrolle. Die Änderung betrifft laut n8n den SSE-Transport; Streamable HTTP bleibt unverändert. Unternehmen mit produktiven MCP-Workflows sollten daher nicht nur prüfen, ob der Aufruf erfolgreich antwortet, sondern auch, ob die gespeicherte Ausführung die erwarteten Tool-Ausgaben vollständig enthält.

Welche Bedeutung haben 2.33.5 und 2.33.6?

Die beiden neuesten Patches sind kleiner. 2.33.5 korrigiert den Fokus im Markdown-Editor. 2.33.6 ergänzt bei der serverseitigen Abfrage bestimmter Feature Flags Versions- und Instanzinformationen. Der dazugehörige Pull Request nennt als Hintergrund Funktionen, deren Rollout von Version oder Instanz abhängt.

Für die meisten produktiven Workflows ist daraus kein akuter Handlungsdruck abzuleiten. Da 2.33.6 aber den aktuellen Stable-Patchstand bildet, ist er der sinnvolle Kandidat für einen geplanten Test innerhalb der 2.33-Linie, sofern keine eigenen Abhängigkeiten dagegensprechen.

Wer sollte den Patch besonders prüfen?

• IT- und Plattformteams mit Self-hosted n8n und internen oder externen Task Runnern.
• Operations-Teams, deren Prozesse JavaScript- oder Python-Code-Nodes enthalten.
• Betreiber im Queue Mode, bei denen Runner-, Worker- und Hauptinstanz gemeinsam zuverlässig funktionieren müssen.
• KI- und Integrationsteams, die n8n über den MCP Server Trigger als Werkzeug für MCP-Clients bereitstellen.
• Support- und Betriebsteams, die bereits Meldungen wie „Task request timed out“ oder unvollständige MCP-Ausführungsdaten beobachten.

Wer keine Code Nodes, Task Runner oder MCP-Trigger verwendet, profitiert zwar vom aktuellen Patchstand, hat wegen dieser beiden Korrekturen aber meist keine besondere Dringlichkeit.

Prüfplan vor dem produktiven Update

1. Versionsstand erfassen: Hauptinstanz, Worker und Runner getrennt dokumentieren.
2. Betroffene Workflows inventarisieren: Code Nodes, externe Runner und MCP Server Trigger markieren.
3. Sicherung und Rollback vorbereiten: Datenbank, Konfiguration und Verschlüsselungsschlüssel nach dem eigenen Betriebsstandard sichern.
4. Komponenten gemeinsam testen: n8n empfiehlt bei verteilten Setups, Hauptinstanz, Worker und Runner versionsgleich zu aktualisieren.
5. Runner-Ausfall simulieren: In einer Testumgebung kontrolliert prüfen, ob Code-Node-Ausführungen nach einem Runner-Neustart wieder funktionieren.
6. MCP-Ausführungsdaten kontrollieren: Einen SSE-basierten Tool-Aufruf ausführen und überprüfen, ob Ein- und Ausgabedaten vollständig gespeichert werden.
7. Nach dem Rollout beobachten: Timeout-Meldungen, fehlgeschlagene Code Nodes, Runner-Neustarts und Ausführungsdauer überwachen.

Ein erfolgreicher manueller Workflow-Start allein reicht als Abnahme nicht aus. Entscheidend ist, ob die tatsächlichen Produktionspfade, Wiederholungen und Fehlerbehandlungen funktionieren. Unser Leitfaden zu n8n Monitoring und Betrieb zeigt, welche Signale dauerhaft überwacht werden sollten.

Was Unternehmen jetzt konkret tun sollten

Prüfen Sie zunächst, ob die beschriebenen Komponenten in Ihrer Umgebung überhaupt genutzt werden. Wenn ja, planen Sie 2.33.6 als kontrolliertes Wartungsupdate ein und testen Sie gezielt den Wiederanlauf der Runner sowie die gespeicherten Daten Ihrer MCP-Ausführungen. Ein Wechsel auf die 2.34.x-Vorabversion ist für diese Korrekturen nicht erforderlich.

Für produktive Systeme gehören Versionswahl, Testprotokoll, Freigabe und Rückfallweg in einen festen Änderungsprozess. Der Beitrag zu n8n Governance beschreibt die organisatorische Seite; unsere Leistung n8n Betrieb und Wartung verbindet Updates mit Backups, Monitoring und Wiederanlauf.

Fazit

n8n 2.33.6 bündelt als aktueller Stable-Patch mehrere kleine, aber betrieblich relevante Korrekturen. Besonders wertvoll sind die robustere Behandlung ausgefallener oder blockierter Task Runner und vollständigere MCP-Ausführungsdaten bei SSE-Aufrufen. Unternehmen sollten deshalb nicht blind aktualisieren, sondern genau diese Pfade in einer realistischen Testumgebung prüfen.

Sie möchten klären, ob Ihre n8n-Instanz betroffen ist oder ein Update ohne Ausfallrisiko vorbereiten? Nehmen Sie Kontakt mit uns auf. Wir prüfen Version, Runner-Konfiguration, MCP-Workflows, Monitoring und Rollback gemeinsam mit Ihrem IT- oder Operations-Team.