Einige n8n-Workflows haben keine Ausführungshistorie

Fragen
1

Beschreibe das Problem/den Fehler/die Frage

Hallo,

Einige Workflows zeigen überhaupt keine Ausführungen an, obwohl sie manchmal stündlich laufen, aber nichts wird angezeigt. Keine Filter gesetzt, keine Einschränkungen in der UI.

Andere Workflows haben eine lebhafte Ausführungshistorie.

Ich habe einige Beiträge zu diesem Problem gesehen, aber die meisten führen zu keiner Lösung. Die eine Proxy-Lösung trifft in meinem Fall nicht zu.

EXECUTIONS_DATA_MAX_AGE=168
EXECUTIONS_DATA_PRUNE_MAX_COUNT=10000
EXECUTIONS_DATA_PRUNE=true

Die Konfigurationen wurden auf der Backend-Seite erhöht, aber das Problem wurde nicht gelöst. Ich habe auch die Workflow-Einstellungen mehrerer Workflows verglichen, die Ausführungen haben und die keine haben. Wenn ich sie manuell auslöse, existieren Ausführungen und werden protokolliert.

Ich beginne zu vermuten, dass jemand die Test-Webhook-URL statt der Produktions-URL verwendet hat, oder vielleicht auf der App-Seite GET eingestellt hat, wenn POST erforderlich ist… Aber ich muss sichergehen, dass mit n8n, dem Setup und dem Server nichts anderes falsch ist.

Wenn sie bereinigt wurden, sollten sie zumindest etwas in den Ausführungen anzeigen.

Wie ist das möglich? Hat jemand dieses Problem schon mal gehabt? Wie hast du es gelöst?

Informationen zu deinem n8n-Setup

  • n8n-Version: Version 2.8.3
  • Datenbank (Standard: SQLite): PostgreSQL (Docker)
  • n8n EXECUTIONS_PROCESS-Einstellung (Standard: own, main): main
  • n8n wird betrieben über (Docker, npm, n8n cloud, Desktop-App): npm
  • Betriebssystem: gehostet auf Ubuntu 24.04.4 LTS, UI auf Chrome/Windows 10/11
3

Hi @dmtr

Deine Webhook-URL-Theorie ist es wert, überprüft zu werden, aber schau dir zuerst etwas Einfacheres an: Jeder Workflow kann die globalen Einstellungen für die Ausführungsspeicherung überschreiben.

Öffne einen betroffenen Workflow → Einstellungen (Zahnrad-Symbol) → überprüfe „Erfolgreiche Produktionsausführungen speichern

4

Hallo @houda_ben,

Workflows sind veröffentlicht.
Einstellungen in den Workflows zum Speichern von Ausführungen sind aktiviert.
Warte auf Feedback vom Team bezüglich der verwendeten URLs und HTTP-Methoden.

6

Wenn die Webhook-URL (Test-Webhook-URL statt der Production-URL) oder die HTTP-Methode falsch ist, dann wird dir in der Execution-Liste überhaupt nichts angezeigt.
Bei beiden Problemen wird eine clientseitige Erfolgsmeldung mit einem 404-Statuscode angezeigt, und nichts wird in den Executions gespeichert.

8

Bevor du weitere Konfigurationen tweakst, solltest du schnell ausschließen: Werden die Workflows tatsächlich ausgelöst, oder werden sie ausgelöst, aber nicht gespeichert? Das kannst du leicht unterscheiden – schau dir die n8n-Logs direkt zu dem Zeitpunkt an, zu dem der Schedule laufen soll. Webhook-Treffer werden standardmäßig in stdout angezeigt; bei Trigger-Auslösungen brauchst du N8N_LOG_LEVEL=debug. Wenn du den Trigger auslösen siehst, aber keine Zeile in execution_entity landet, ist es ein Save-Path-Problem. Wenn du zur geplanten Zeit gar nichts siehst, wird der Workflow überhaupt nicht ausgelöst.

Zwei häufige stille Übeltäter: der Active-Schalter ist deaktiviert (gespeicherte, aber inaktive Workflows sehen in der Liste identisch aus und sind leicht zu übersehen, wenn du Dutzende hast), oder globales Execution Pruning trimmt Durchläufe, wenn du viele stündliche Schedules hast. Es lohnt sich, diese beiden auszuschließen, bevor du dich in etwas Komplizierteres vertiefst.

9

Das Problem wurde identifiziert. Das Problem ist, dass die Workflows etwa 17k Ausführungen pro Tag haben. Das Erhöhen des Standards von 10k und 7 Tagen auf 50k und 30 Tage hatte wenig Auswirkungen, da nach 3 Tagen das Pruning bereits begann (50k-Limit). Dies führte dazu, dass Ausführungen mit geringerem Volumen gelöscht und Ausführungen mit hohem Volumen beibehalten wurden. Das 50k-Limit gilt für alle Workflows, nicht für einzelne.

Jetzt habe ich 3 Optionen. Welche empfiehlst du?

1.) Ausführungslimit auf 250k setzen, was wahrscheinlich eine größere Festplattengröße zum Speichern benötigt

2.) Größenlimit deaktivieren und nur zeitgestütztes (30-Tage-)Pruning durchführen. Dies benötigt auch mehr Festplattenspeicher

3.) Aktualisieren der Workflow-Einstellungen der aktivsten Workflows, um nur fehlgeschlagene Ausführungen zu speichern – oder sie optimieren, um die Ausführungsmengen zu reduzieren.

Das Pruning komplett zu deaktivieren macht keinen Sinn.

[EDIT] die Anzahl der Workflows wird wachsen und monatliche Ausführungen sind etwa 517k, ich denke nicht, dass das Limit auf 750k zu setzen der richtige Weg ist

10

Hi dmtr - mit den neuen Details sieht das weniger nach einem Webhook-/Test-URL-Problem aus und eher nach einem Execution-Retention-Sizing-Problem: etwa 17.000 Ausführungen/Tag bedeuten, dass ein globales Limit von 50.000 Einträgen nach etwa drei Tagen mit dem Löschen beginnen kann, und das Limit wird über alle Workflows hinweg geteilt, statt pro Workflow reserviert zu sein.

Die Abwägung ist nicht nur „Limit erhöhen