Begriff
Execution (n8n)
Warum wichtig?
Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.
Eine Execution ist ein Eintrag im Logbuch deines Roboters. Jedes Mal, wenn dein Workflow startet (egal ob durch Trigger oder Klick), legt n8n eine neue Akte an: "Execution ID 1234". In dieser Akte steht alles, was passiert ist:
Wann ging es los?
Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Eine Execution ist ein Eintrag im Logbuch deines Roboters. Jedes Mal, wenn dein Workflow startet (egal ob durch Trigger oder Klick), legt n8n eine neue Akte an: "Execution ID 1234". In dieser Akte steht alles, was passiert ist: Wann ging es los? Welche Daten kamen rein? Welcher Node hat was gemacht? Gab es Fehler?Welche Daten kamen rein?
Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Eine Execution ist ein Eintrag im Logbuch deines Roboters. Jedes Mal, wenn dein Workflow startet (egal ob durch Trigger oder Klick), legt n8n eine neue Akte an: "Execution ID 1234". In dieser Akte steht alles, was passiert ist: Wann ging es los? Welche Daten kamen rein? Welcher Node hat was gemacht? Gab es Fehler?Welcher Node hat was gemacht?
Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Eine Execution ist ein Eintrag im Logbuch deines Roboters. Jedes Mal, wenn dein Workflow startet (egal ob durch Trigger oder Klick), legt n8n eine neue Akte an: "Execution ID 1234". In dieser Akte steht alles, was passiert ist: Wann ging es los? Welche Daten kamen rein? Welcher Node hat was gemacht? Gab es Fehler?Gab es Fehler?
Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Eine Execution ist ein Eintrag im Logbuch deines Roboters. Jedes Mal, wenn dein Workflow startet (egal ob durch Trigger oder Klick), legt n8n eine neue Akte an: "Execution ID 1234". In dieser Akte steht alles, was passiert ist: Wann ging es los? Welche Daten kamen rein? Welcher Node hat was gemacht? Gab es Fehler?
Wenn du dich fragst: "Warum hat der Kunde gestern keine E-Mail bekommen?", schaust du in die Executions. Das ist deine Zeitmaschine für die Fehlersuche.
Merksatz: Das Protokoll eines einzigen Durchlaufs eines Workflows.
Die Executions-Liste
Du findest sie in der linken Seitenleiste unter "Executions". Dort siehst du eine Ampel-Liste:
- 🟢 Success: Alles lief glatt.
- 🔴 Error: Der Workflow ist abgebrochen.
- 🟡 Running: Er läuft gerade noch (z. B. bei langen Wartezeiten).
Debugging (Fehlersuche)
Klicke auf eine rote Execution. Du siehst dann den Workflow-Editor, aber "eingefroren" in der Zeit von gestern.
- Der kaputte Node ist rot umrandet.
- Wenn du ihn anklickst, siehst du genau die Fehlermeldung: "Error: E-Mail address missing".
- Du siehst auch, welche Daten vorher reinkamen. So kannst du beweisen: "Aha, Shopify hat gar keine E-Mail geschickt!"
1. Speicherplatz & Pruning
Executions fressen Festplattenplatz. Ein einziger Lauf mit vielen PDF-Dateien kann 50 MB groß sein. Bei 1000 Läufen am Tag ist dein Server nach einer Woche voll. Deshalb musst du "Data Pruning" aktivieren (in den Environment Variables oder Workflow Settings):
EXECUTIONS_DATA_SAVE_ON_ERROR=all(Speichere Fehler immer komplett).EXECUTIONS_DATA_SAVE_ON_SUCCESS=none(Speichere Erfolge gar nicht oder ohne Daten, nur Status).EXECUTIONS_DATA_MAX_AGE=168(Lösche alles, was älter als 7 Tage ist).
2. Execution ID & Retry
Jede Execution hat eine einzigartige ID (z. B. 256).
Wenn eine Execution wegen eines temporären Fehlers (API down) fehlschlug, kannst du sie retryen (erneut versuchen).
n8n nimmt dann exakt dieselben Start-Daten von damals und lässt den Workflow nochmal laufen.
Das ist super wichtig für kritische Prozesse (Rechnungsstellung).
3. Concurrency (Gleichzeitigkeit)
Standardmäßig können Workflows parallel laufen. Wenn 100 Webhooks gleichzeitig kommen, starten 100 Executions. Das kann deinen Server überlasten. Du kannst es drosseln (Settings -> "Max Interactions"): "Maximal 5 Executions gleichzeitig". Die anderen warten in einer Warteschlange.
Queue-basierte Execution Architecture (Redis & Workers)
Im main Modus drückt der n8n-Daemon jede Execution in den NodeJS-Main-Thread ab. Bei 30 Workflows pro Sekunde kollabiert die NodeJS V8.
Um n8n für Milliarden-Pakete "Production-Ready" zu machen, stellt man in der Architektur auf den Queue/Worker Mode um.
Der n8n-Master-Container nimmt den Webhook nur noch an, speichert die ExecutionID ab und pusht das Job-Payload in einen Message Broker (z.B. Redis als bullMQ).
Dutzende n8n-Worker-Nodes, die in einem Kubernetes-Cluster über Horizontal Pod Autoscaling (HPA) gestreut laufen, lesen die Jobs (die "Executions") aus Redis ("Pull Pattern"), reiten die HTTP-Calls ab und schreiben die Log-Files in die Postgres-DB. Der Master-Container bleibt jederzeit performant.
Wait-Nodes und State Recovery (Hydration)
Wenn ein Workflow einen Wait-Node nutzt ("Warte 14 Tage auf Klickbestätigung der E-Mail"), bleibt die Execution "Running".
Technologisch wäre es katastrophal, wenn NodeJS diesen State 14 Tage im RAM hält.
Sobald der Wait-Node greift, wirft n8n ein "State Checkpoint" Snapshot in die Datenbank und killt den aktiven Thread. Der Speicher ist frei.
Triggert nach 14 Tagen das Resume-Signal (z.B. User klickt auf Link), "rehydriert" n8n die Execution. Es zieht sich das Snapshot (die letzten Knoten-Outputs) aus der Disk, spawnt einen frischen V8 Context, lädt den Zustand rein und macht genau bei Node Z weiter. Das Überstehen von System-Neustarts bei blockierten Executions nennt man "Robust Persistence".
Prometheus, Grafana und Metrics Exporter
Die eingebaute GUI-Liste der Executions ist für Admins ("NOC Team") blind.
Man will Graphen. EXECUTIONS_TIMEOUT_MAX reicht da nicht.
Die API-Knoten in n8n spucken Telemetrie-Daten aus (in Prometheus-kompatiblem Format oft über Custom /metrics Endpunkte). Ein externer Prometheus-Scraper pollt n8n alle 10 Sekunden. Admins bauen Grafana-Dashboards, um visuell Error-Raten zu korrelieren ("Wenn Stripe API einen Spike in Timeouts verzeichnet, geht Error-Rate von Workflow #42 massiv hoch"). Es transformiert isolierte Logs in systemisches Observability.
Quick-Check
Warum speichert man Executions nicht für immer?
Weil sie massiv Speicherplatz verbrauchen. JSON-Daten von tausenden Läufen füllen jede Festplatte schnell.Was kannst du tun, wenn eine wichtige Execution (z. B. Rechnung versenden) fehlgeschlagen ist?
Du öffnest die Execution und klickst auf "Retry". n8n versucht es dann erneut mit den originalen Daten.Wie findest du heraus, an welchem Node es geklemmt hat?
In der Executions-Ansicht ist der fehlerhafte Node rot markiert. Ein Klick darauf zeigt die genaue Fehlermeldung der API.