Entschuldigung, ich bin neu bei n8n und benötige Anleitung für ein Projekt in meinem Team.
Wir verlagern unsere n8n-Infrastruktur auf ein Drei-Umgebungs-Modell und möchten sicherstellen, dass wir verstehen, wie Ausführungen gezählt werden, bevor wir eine Lizenzquote mit n8n vereinbaren.
Unsere Infrastruktur
3 selbstgehostete Instanzen: ST (Entwicklung/Build), SIT (Integrationstests) und PROD
Promotion über Git: ST → SIT → PROD über Merge Requests (Versionskontrolle / Umgebungen-Feature)
~185 Workflows im Umfang nach Bereinigung (von ~270 heute). Viele davon werden zeitgesteuert ausgelöst, und eine große Gruppe ruft sich gegenseitig als Sub-Workflows auf.
Unsere Lizenzquote gilt für alle Instanzen kombiniert
Aktuelle Zahlen (ca., pro Monat)
PROD: ~20–30k Ausführungen
ST: ~28k Ausführungen. Fast alle stammen von geplanten Workflows, die 24/7 aktiv bleiben, auch am Wochenende.
SIT: sehr gering (ein paar hundert)
Unsere Nicht-Produktionsinstanz verursacht derzeit mehr Ausführungen als die Produktion, was falsch zu sein scheint.
Fragen zur Zählung von Ausführungen
Welche Ausführungen zählen zur Quote? Zählen nur Produktionsausführungen (aktive Workflows, die durch einen Trigger gestartet werden), oder zählen auch manuelle Läufe aus dem Editor?
Zählen Sub-Workflow-Aufrufe (Execute Workflow-Node) als separate Ausführungen?
Zählen fehlgeschlagene Ausführungen, Wiederholungen und Error-Workflows?
Bei einer Quote, die über Instanzen verteilt ist, wird die Zählung pro Lizenzschlüssel aggregiert? Gibt es eine empfohlene Methode, die Nutzung pro Instanz zu überwachen, bevor das Limit erreicht wird?
Fragen zu Umgebungen und Ausführungsvolumen
Wie gehen Sie mit zeitgesteuerten Triggern in nicht-produktiven Instanzen um? Halten Sie Workflows in ST/SIT standardmäßig inaktiv und aktivieren sie diese nur während des Testens? Oder haben Sie eine Möglichkeit, Trigger automatisch zu deaktivieren, wenn Sie aus Git abrufen?
Best Practices zur Reduzierung des Ausführungsvolumens, ohne Funktionalität zu verlieren? Zum Beispiel:
Ersetzen von Polling-Zeitplänen durch Webhooks
Reduzierung der Häufigkeit von Zeitplänen
Zusammenführung von Sub-Workflows
Frühes Filtern, damit Läufe nicht unnötig erfolgen
Wie bemessen Sie die Lizenzquote, wenn Sie mehrere Umgebungen haben? Legen Sie ein Budget pro Umgebung fest?
Richten Sie Benachrichtigungen zu täglichen Ausführungszahlen ein? Wir hatten einen Anstieg von etwa 6k Ausführungen pro Tag für zwei Monate, das wir erst nachträglich bemerkt haben.
Erfahrungen, Muster oder Hinweise auf Dokumentation würden sehr geschätzt. Danke!
Was ist die Fehlermeldung (falls vorhanden)?
Bitte teile deinen Workflow
(Wähle die Knoten auf deiner Leinwand aus und verwende die Tastaturkürzel CMD+C/STRG+C und CMD+V/STRG+V, um den Workflow zu kopieren und einzufügen.)
Nur Produktionsausführungen zählen zu deinem Kontingent. Dies sind Ausführungen, die automatisch durch einen Trigger (Zeitplan, Webhook, Polling usw.) gestartet werden und im Hintergrund laufen. Manuelle Läufe (Klick auf „Execute Workflow
akurt, bei ST mit 28.000 Durchläufen pro Monat würde ich mit den Zeitplänen anfangen, die außerhalb des eigentlichen Testens aktiviert bleiben.
Ein Fünf-Minuten-Zeitplan bedeutet 288 Starts pro Tag oder 8.640 über 30 Tage. Ein IF, das beendet wird, weil keine Arbeit vorhanden ist, kann nachgelagerte API-Aufrufe sparen, aber der Zeitplan hat bereits eine Ausführung gestartet. Die Quota-Dokumentation unterscheidet das von einem Polling-Trigger, der keine neuen Daten zurückgibt. Ich würde überprüfen, welchen Typ jeder hochvolumigen Workflow tatsächlich verwendet, bevor ich Einsparungen abschätze.
Für ST/SIT würde ich geplante Entry-Workflows standardmäßig nicht veröffentlichen. Zeichne für jeden geplanten Integrationtest auf, welche Workflows ausgeführt werden müssen, wer der Test-Eigentümer ist und wann sie wieder unveröffentlicht werden sollten. Halte diese Richtlinie getrennt von deinem Workflow-Code, damit die Förderung der gleichen Logik nicht bedeutet, dass die Zeitpläne in jeder Umgebung ausgeführt werden. Nutze Test-Anmeldedaten und behalte alle Zeitpläne, die für den Test tatsächlich erforderlich sind.
Es gibt hier ein nützliches Git-Detail: Auto publish Off bedeutet „den aktuellen lokalen Veröffentlichungsstatus beibehalten
Ihre vorhandenen Antworten erklären die Zählregeln, aber die verbleibende praktische Aufgabe besteht darin, herauszufinden, welche Ihrer ST-Workflows für die 28.000 Ausführungen verantwortlich sind, und zu entscheiden, welche Zeitpläne für Tests aktiv bleiben müssen.
Falls diese Prüfung noch erforderlich ist, kann ich eine pauschal gebührenfreie, schreibgeschützte Überprüfung von bis zu 200 redigierten ST/SIT/PROD-Workflow-Exporten und einer entsprechenden siebentägigen Ausführungszusammenfassung für 79 US-Dollar anbieten. Das Ergebnis ist eine Zeitplanbestandsaufnahme, ein Vergleich konfiguriert versus beobachtet, priorisierte Änderungen zur Genehmigung durch Ihr Team sowie eine Checkliste für Verantwortliche/Test-Ende. Kalender-/Cron-Regeln und Unterschiede zwischen exportierten und veröffentlichten Versionen würden zur Überprüfung gekennzeichnet, nicht erraten.
Die Lieferung würde zwei Geschäftstage nach Vereinbarung des Umfangs und Erhalt der redigierten Eingaben erfolgen, mit einer Korrektur oder Klarstellung. Ich nutze KI-gestützte Analysen und habe ein lokales Bestandsverwaltungstool, das gegen synthetische Exporte überprüft wird; diese Überprüfungen sind keine Aussage über Ihre Instanz oder Abrechnung. Es sind keine Kontoanmeldedaten oder Live-Änderungen erforderlich. Bitte halten Sie Token und Geschäfts-/Personendaten aus öffentlichen Beiträgen heraus.
Ist dies immer noch hilfreich, und können Sie diese begrenzte Überprüfung in Auftrag geben? PayPal Goods and Services ist verfügbar.