> ## Content Index > Fetch the complete content index at: https://relvro.de/llms.txt > Use this file to discover other available public pages before exploring further. # n8n Executions berechnen: Wie viele Workflow-Läufe erzeugen Schedule, Polling und Webhooks? - URL: https://relvro.de/n8n-executions-berechnen/ - Published: 2026-10-02T00:27:52.000Z - Updated: 2026-10-27T19:26:00.000Z - Description: Wie viele n8n Executions erzeugen Schedule, Polling und Webhooks? So berechnest du deinen monatlichen Verbrauch und verstehst die Unterschiede zwischen den Triggern. - Author: ILYAS‬‏ - Tags: Automation Wenn du n8n Cloud nutzt, steht in deinem Tarif eine bestimmte Zahl an **Workflow Executions** zur Verfügung. Die entscheidende Frage ist deshalb nicht nur, wie viele Executions dein Tarif enthält. Viel wichtiger ist: **Wie viele Workflow-Läufe erzeugen deine Automatisierungen tatsächlich pro Monat?** Ein Workflow, der einmal täglich startet, kommt bei ungefähr 30 Ausführungen im Monat auf eine völlig andere Größenordnung als ein Workflow, der alle fünf Minuten läuft. Letzterer kann bereits auf **8.640 Ausführungen in 30 Tagen** kommen. Damit du dein Kontingent realistisch einschätzen kannst, musst du deshalb verstehen, **was eine Execution auslöst, wie oft ein Workflow startet und welche Zählregel für den jeweiligen Trigger gilt.** ## Was zählt bei n8n als Execution? Eine **Execution** ist ein vollständiger Lauf eines Workflows. Für n8n Cloud ist dabei nicht entscheidend, wie viele Nodes dein Workflow enthält. Die Abrechnung orientiert sich an den **Workflow Executions** und nicht daran, wie viele einzelne Steps innerhalb eines Laufs verarbeitet werden. Das macht einen wichtigen Unterschied: - 5 Nodes können zu 1 Workflow Execution gehören. - 50 Nodes können ebenfalls zu 1 Workflow Execution gehören. - Entscheidend ist zunächst, **wie oft der Workflow ausgeführt wird**. Die aktuellen n8n-Tarife basieren auf monatlichen Workflow Executions, unabhängig von der Anzahl der Schritte innerhalb eines Workflows. [n8n: aktuelle Preise und Execution-Modell](https://n8n.io/pricing/?ref=relvro.de) Die nächste Frage lautet: > **Was sorgt dafür, dass dein Workflow überhaupt startet?** ## Welche Trigger erzeugen Executions? Für die Praxis sind drei Fälle besonders wichtig: - **Schedule:** Der Workflow startet nach einem Zeitplan. - **Polling:** Ein Trigger prüft regelmäßig, ob neue Daten vorhanden sind. - **Webhook:** Eine eingehende Anfrage löst den Workflow aus. Diese Trigger müssen bei der Verbrauchsschätzung unterschiedlich betrachtet werden. ## 1\. Schedule: Jede geplante Ausführung zählt Bei einem Schedule Trigger ist die Berechnung vergleichsweise einfach. Wenn dein Workflow beispielsweise einmal täglich läuft: **1 Ausführung × 30 Tage = ca. 30 Executions pro Monat** Je kürzer das Intervall, desto höher der mögliche Verbrauch. ### Beispiel: alle 5 Minuten Ein Workflow, der alle fünf Minuten startet, wird theoretisch: - 12-mal pro Stunde - 288-mal pro Tag - **8.640-mal in 30 Tagen** ausgeführt. Die Rechnung lautet: **12 × 24 × 30 = 8.640** Bei 31 Tagen wären es **8.928 Executions**. Damit kann ein einziger Workflow bereits einen großen Teil eines kleineren Execution-Kontingents verbrauchen. Bei einem häufigen Schedule solltest du deshalb nicht nur fragen: > „Wie oft brauche ich eine Prüfung?“ Sondern auch: > **„Muss dieser Workflow wirklich so häufig vollständig ausgeführt werden?“** ## 2\. Webhook: Verbrauch hängt von den tatsächlichen Auslösungen ab Ein Webhook funktioniert anders. Statt einen Workflow regelmäßig nach einem festen Zeitplan zu starten, wartet der Workflow auf eine eingehende Anfrage. Wenn beispielsweise durchschnittlich 15 Requests pro Tag den Workflow tatsächlich auslösen, ergibt sich: **15 × 30 = 450 Executions pro Monat** Wichtig ist dabei die genaue Trigger-Logik. Entscheidend ist, ob die Anfrage den entsprechenden Webhook-Trigger tatsächlich aktiviert und damit einen Workflow-Lauf startet. n8n dokumentiert außerdem, dass ein gültiger Request mit leerem JSON-Objekt den Webhook auslösen kann. Requests, die den Workflow bereits vor dem eigentlichen Start wegen eines ungültigen Requests nicht auslösen, werden anders behandelt. [n8n Webhook-Dokumentation](https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.webhook/?ref=relvro.de) ### Die praktische Rechnung Wenn du weißt, wie viele echte Ereignisse deinen Workflow auslösen, kannst du zunächst überschlagen: **Events pro Tag × Tage pro Monat = mögliche monatliche Workflow-Läufe** Bei: **15 Events × 30 Tage = 450** liegt der rechnerische Verbrauch also bei ungefähr 450 Workflow-Läufen. ## 3\. Polling: Nur neue Daten können einen Lauf auslösen Polling ist der Fall, bei dem eine einfache Frequenzrechnung schnell zu falschen Ergebnissen führen kann. Ein Polling-Trigger prüft regelmäßig eine Datenquelle darauf, ob neue Daten vorhanden sind. Bei einem entsprechenden Polling-Trigger zählt die Prüfung als Execution, **wenn neue Daten gefunden werden**. Ein Poll ohne neue Daten verbraucht dagegen keine Execution. Deshalb wäre diese Schlussfolgerung zu einfach: > „Polling alle fünf Minuten = automatisch 8.640 Executions.“ Die theoretische Obergrenze bei einer Prüfung alle fünf Minuten liegt zwar bei 8.640 Prüfungen in 30 Tagen. Für den tatsächlichen Execution-Verbrauch ist aber entscheidend, **wie oft der Trigger dabei neue Daten findet und einen Workflow-Lauf erzeugt**. Das bedeutet: **Prüffrequenz ≠ automatisch Execution-Verbrauch.** Für eine realistische Schätzung solltest du deshalb getrennt betrachten: 1. Wie häufig wird geprüft? 2. Wie oft werden tatsächlich neue Daten gefunden? 3. Wie viele Workflow-Läufe entstehen daraus? 4. Wie viele Executions ergeben sich daraus pro Monat? Wenn beispielsweise alle fünf Minuten geprüft wird, aber nur bei einem Teil der Prüfungen neue Daten vorhanden sind, liegt der tatsächliche Verbrauch entsprechend unter der reinen Zahl der Prüfungen. [n8n: Understand executions](https://docs.n8n.io/build/understand-workflows/understand-executions?ref=relvro.de) ## Was zählt nicht zum normalen Production-Verbrauch? Bei der eigenen Verbrauchsrechnung solltest du außerdem zwischen unterschiedlichen Ausführungsarten unterscheiden. Für die praktische Planung des monatlichen Production-Verbrauchs sind insbesondere die **Production Executions** relevant. Nicht jede Ausführung, die du während der Entwicklung oder beim Testen manuell startest, entspricht deshalb automatisch einer zusätzlichen Production Execution im gleichen Sinn. Auch Sub-Workflow- und Error-Workflow-Ausführungen müssen anhand der aktuellen n8n-Zählregeln betrachtet werden, statt sie pauschal zu den normalen Trigger-Ausführungen zu addieren. Für eine konkrete Abrechnung solltest du deshalb die offizielle n8n-Dokumentation **„Understand executions“** als Referenz verwenden. [n8n: Understand executions](https://docs.n8n.io/build/understand-workflows/understand-executions?ref=relvro.de) ## Die wichtigsten Trigger im Vergleich | Workflow | Trigger | Frequenz / Ereignisse | Geschätzte Executions | | ---------------- | -------- | ------------------------ | --------------------- | | Täglicher Report | Schedule | 1 × täglich | ca. 30 | | Häufiger Check | Schedule | alle 5 Min. | 8.640 | | Event-Workflow | Webhook | 15 Events/Tag | ca. 450 | | Polling | Polling | abhängig von neuen Daten | konkret berechnen | Damit bekommst du ein realistischeres Bild davon, wie schnell dein Execution-Kontingent verbraucht werden kann. ## Welche n8n-Tarife sind aktuell relevant? Die aktuelle Preisstruktur zeigt unter anderem: - **Starter:** 2.500 Workflow Executions - **Pro:** 10.000 Workflow Executions - **Pro-2:** 50.000 Workflow Executions - **Business:** 40.000 Executions; aktuell als Self-hosted-Angebot ausgewiesen Bei Pro-2 Monthly können zusätzliche Executions bis zu insgesamt **500.000 monatlichen Executions** konfiguriert werden. Zwischen Pro mit 10.000 und Pro-2 mit 50.000 Executions gibt es keine weitere reguläre Execution-Stufe. Die Preise und Planbedingungen können sich ändern. Deshalb solltest du für eine konkrete Kaufentscheidung immer die aktuelle n8n-Preisseite prüfen. [Aktuelle n8n-Preise prüfen](https://n8n.io/pricing/?ref=relvro.de) Für die eigentliche Execution-Berechnung ist jedoch wichtiger, **wie viele Runs deine Workflows erzeugen**, als eine Preistabelle auswendig zu kennen. ## Was passiert, wenn das Execution-Limit erreicht ist? Bei n8n Cloud werden neue durch Trigger oder Webhooks ausgelöste Executions nach Erreichen des monatlichen Limits **nicht in eine Warteschlange gestellt**. Die Execution wird erstellt und schlägt unmittelbar mit einem Fehler wegen des erreichten Limits fehl. Es entsteht also kein Backlog, das n8n automatisch im nächsten Monat nachholt. Das gilt aktuell für Trial, Starter, Pro-1 und Pro-2\. Fehlgeschlagene Executions aufgrund des erreichten Limits zählen nicht gegen das Execution-Kontingent. Wenn du eine solche fehlgeschlagene Ausführung später erneut ausführen möchtest, musst du sie manuell aus der Execution-Übersicht erneut starten. [n8n Help Center: Execution-Limit und Reset](https://support.n8n.io/article/can-you-reset-my-executions?ref=relvro.de) ### Execution Quota ist nicht dasselbe wie Concurrency Diese beiden Dinge solltest du nicht miteinander verwechseln. **Execution Quota** \= Wie viele Executions in einem Kalendermonat für deinen Plan zur Verfügung stehen. **Concurrency** \= Wie viele Ausführungen gleichzeitig verarbeitet werden können. Eine Concurrency-Begrenzung kann dazu führen, dass Ausführungen warten. Das Erreichen des monatlichen Execution-Limits ist dagegen kein normaler Concurrency-Queue-Fall. Die Execution-Limits werden zu Beginn jedes **Kalendermonats** zurückgesetzt, unabhängig vom eigentlichen Abrechnungsdatum. ## Was ist der Unterschied zwischen Pro und Pro-2? Wenn deine berechnete Nutzung über 10.000 Executions pro Monat hinausgeht, wird die nächste reguläre Pro-Stufe relevant: - **Pro:** 10.000 Executions - **Pro-2:** 50.000 Executions Zwischen diesen beiden Stufen gibt es keine weitere reguläre Execution-Stufe. Für Pro-2 Monthly können zusätzliche Execution-Kontingente bis zu **500.000 Executions pro Monat** konfiguriert werden. [n8n Support: Pro-2 Execution-Limits](https://support.n8n.io/article/how-to-modify-your-custom-plan-execution-limits-yermygbc2tk96rqg24r4ajdp?ref=relvro.de) Wenn du beispielsweise bei ungefähr 9.000 Executions liegst, ist deine Situation eine andere als bei 25.000 oder 45.000\. Deshalb ist die eigene Verbrauchsrechnung wichtiger als die bloße Auswahl eines Plans anhand des Namens. ## So berechnest du deinen eigenen Execution-Verbrauch Du brauchst dafür keine komplizierte Formel. Gehe Workflow für Workflow durch. ### Schritt 1: Trigger identifizieren Frage: > **Was startet diesen Workflow?** Zum Beispiel: - Schedule - Webhook - Polling - anderer Trigger ### Schritt 2: Frequenz oder Ereignisse bestimmen Bei Schedule: > Wie oft läuft er? Bei Webhook: > Wie viele echte Ereignisse erwarten wir? Bei Polling: > Wie oft werden neue Daten gefunden und dadurch tatsächliche Workflow-Läufe ausgelöst? ### Schritt 3: Monatlichen Verbrauch schätzen Beispiele: **1 × täglich** → ca. 30 Runs **alle 5 Minuten** → 8.640 Runs in 30 Tagen **15 Webhook-Ereignisse täglich** → ca. 450 Runs **Polling** → abhängig davon, wie oft der konkrete Trigger neue Daten findet. ### Schritt 4: Alle relevanten Workflows addieren Beispiel: - Workflow A: 30 - Workflow B: 450 - Workflow C: 2.000 - Workflow D: 4.000 **Gesamt: ca. 6.480 Executions/Monat** Erst diese Summe zeigt dir, ob ein bestimmtes Kontingent für dein Setup realistisch ist. ## Wo kannst du Execution-Verbrauch reduzieren? Die erste Frage sollte nicht lauten: > „Wie kann ich n8n irgendwie billiger machen?“ Sondern: > **„Warum wird dieser Workflow so häufig gestartet?“** Besonders bei häufigen Schedule- oder Polling-Workflows lohnt sich ein Blick auf die Trigger-Architektur. Wenn ein System eine zuverlässige Event-Schnittstelle bietet, kann ein eventbasierter Trigger möglicherweise unnötig häufige Prüfungen vermeiden. Aber: **Webhook ist nicht automatisch immer besser oder günstiger.** Ein eventbasierter Ansatz muss technisch verfügbar sein und zum konkreten Prozess passen. Die richtige Entscheidung hängt deshalb davon ab, **wie das Quellsystem Ereignisse bereitstellt und welche Workflow-Logik du tatsächlich benötigst.** ## Was hat die Anzahl der Nodes damit zu tun? Für die monatliche Execution-Zahl zunächst weniger, als viele vermuten. Ein Workflow mit: **5 Nodes** kann einen vollständigen Workflow-Lauf darstellen. Ein anderer Workflow mit: **50 Nodes** kann ebenfalls einen vollständigen Workflow-Lauf darstellen. Wenn beide jeweils einmal ausgeführt werden, entsteht nicht automatisch eine zehnmal so große Execution-Abrechnung für den längeren Workflow. Das bedeutet: > **Node-Anzahl und Execution-Anzahl sind zwei unterschiedliche Größen.** Für die Frage nach dem monatlichen Execution-Kontingent solltest du deshalb zuerst die **Workflow-Läufe** zählen. ## Und was ist mit n8n Self-hosted? Bei Self-hosted n8n verschiebt sich die Kosten- und Betriebsfrage. Die Community Edition ist eine separate kostenlose Self-hosted-Variante. Bei den kostenpflichtigen Self-hosted-Angeboten wie Business und Enterprise gelten dagegen eigene Lizenz- und Nutzungsbedingungen. Für Business nennt n8n aktuell 40.000 Workflow Executions. Bei Überschreitung des Kontingents können dort andere Bedingungen und zusätzliche Kosten gelten als bei den Cloud-Plänen. Die grundsätzliche Entscheidung zwischen Cloud und Self-hosted ist eine andere Frage: > **Soll n8n Cloud oder Self-hosted zu deinem Betriebsmodell passen?** Diese Entscheidung behandelt unser separater Artikel zu Cloud vs. Self-hosted ausführlicher. [n8n Cloud oder Self-Hosted: Was passt zu dir?](https://relvro.de/n8n-cloud-self-hosted/) Hier geht es dagegen um die engere Frage: > **Wie entstehen Workflow Executions und wie viel davon erzeugt mein Setup?** ## Wo kannst du deinen tatsächlichen Verbrauch prüfen? Für die laufende Kontrolle solltest du nicht nur auf die Anzahl gespeicherter Executions schauen. n8n stellt für die Production-Nutzung ein **Insights Dashboard** bereit, über das du deine Production Execution Counts prüfen kannst. Das ist für die Verbrauchskontrolle aussagekräftiger als lediglich zu zählen, wie viele Ausführungen noch in der Execution-Historie sichtbar sind. ## Fazit: Nicht den Tarif zuerst wählen – den Verbrauch zuerst verstehen Die wichtigste Zahl bei n8n Cloud ist nicht einfach: > „Mein Tarif hat 2.500 oder 10.000 Executions.“ Du solltest zuerst verstehen, **wie dein Workflow diese Executions erzeugt**. Die einfache Denkweise lautet: **Trigger → Zählregel → Häufigkeit bzw. Ereignisse → monatliche Executions → Kontingent** Bei einem Schedule kannst du die Frequenz relativ direkt berechnen. Bei einem Webhook kannst du mit der erwarteten Zahl echter Events arbeiten. Bei Polling musst du dagegen berücksichtigen, dass nicht jede Prüfung automatisch zu einer Execution führt. Entscheidend ist, wann der konkrete Trigger neue Daten findet und dadurch einen Workflow-Lauf auslöst. Und wenn dein Kontingent erreicht wird, solltest du Execution Quota nicht mit einer Concurrency-Warteschlange verwechseln. Genau deshalb lohnt es sich, den eigenen Execution-Verbrauch **vor** der Tarifentscheidung zu berechnen. Denn die bessere Frage ist nicht: > **„Welcher n8n-Tarif ist der beste?“** Sondern: > **„Wie viele Workflow Executions erzeugt mein tatsächliches Setup – und welches Kontingent passt dazu?“**