Zapier vs. Make vs. n8n: Preisvergleich bei echtem Volumen (2026)

Jede Automatisierungsplattform zählt Nutzung anders, und das ist kein Zufall. Zapier rechnet pro Task, Make.com pro Operation, n8n pro Execution. Diese drei Wörter sehen auf einer Pricing-Seite austauschbar aus. Sind sie nicht. Derselbe Workflow kann 208 $ auf Zapier, 20 $ auf Make oder den Preis eines VPS auf selbst gehostetem n8n kosten.

Dieser Leitfaden ist ein Praktiker-Walkthrough, wie jede Plattform zählt, wo die versteckten Kosten lauern und welche Plattform bei welcher Volumen-Band tatsächlich gewinnt. Ich fahre produktive Workflows auf Make und n8n für eigene Produkte (Teedian, eine Content-Operations-Engine), also spiegeln die Beispiele reale Verdrahtung wider, keine Marketing-Mathematik.

Das kurze Fazit: unter 500 Läufen pro Monat funktioniert fast jedes Free-Tier. Zwischen 500 und 5.000 Läufen pro Monat ist Make.com Core der Sweet Spot. Oberhalb 5.000 gewinnt selbst gehostetes n8n fast immer, wenn Sie die Ops-Kapazität haben. Zapier gewinnt selten bei Kosten oberhalb des Starter-Tiers — ist aber häufig der schnellste Weg, etwas zu shippen.

Warum Preisvergleiche schwer sind

Drei Gründe, warum Preisvergleiche zwischen Automatisierungsplattformen fast immer in die Irre führen.

Erstens: die Einheiten sind verschieden. Ein Zapier-Task ist ein Aktionsschritt. Eine Make-Operation ist eine Modul-Ausführung. Eine n8n-Execution ist ein vollständiger Workflow-Lauf. Dieselbe Logik auf allen drei zählt Zapier viermal, Make sechsmal, n8n einmal.

Zweitens: Loops, Filter und Error-Handler zählen auf jeder Plattform anders. Make zählt jede Iteration innerhalb eines Loops und Branches innerhalb eines Error-Handlers. Zapier zählt Pfade als separate Multi-Step-Features. n8n interessiert sich nicht, wie viele Nodes Sie haben — nur wie oft der Workflow lief.

Drittens: Retries und Polling blähen Rechnungen still auf. Wenn ein Lauf scheitert und dreimal retryt, sind das 3× Nutzung auf Zapier und Make, und 3× Execution-Count auf n8n Cloud. Polling-Trigger, bei denen die Plattform alle paar Minuten eine API checkt, können eine Quota sprengen, bevor überhaupt Arbeit passiert.

Sie können keine Listenpreise vergleichen. Sie müssen denselben Workflow, beim gleichen realistischen Volumen, mit Retries und Fehlerpfaden vergleichen.

Zapier: Tasks erklärt

Zapier rechnet pro Task. Ein Task ist jeder erfolgreiche Aktionsschritt in einem Zap. Der Trigger zählt nicht. Jeder folgende Schritt schon.

Ein 5-Schritt-Zap, der 100-mal pro Monat feuert, verbraucht 400 Tasks — der Trigger ist frei, die vier Aktionsschritte zählen je einmal pro Lauf. Ein 10-Schritt-Zap bei 100 Fires verbraucht 900 Tasks. Paths, Filter und Iteration-Features multiplizieren das weiter.

Aktuelles Zapier-Pricing, 2026:

Der Sprung von Professional zu Company ist 25× das Task-Allotment, aber nur 2,8× der Preis — die Per-Task-Kosten fallen deutlich, wenn Sie tatsächlich alle 50.000 nutzen. Die meisten Company-Tier-Käufer zahlen für Compliance, nicht Volumen.

Wo Zapier schnell teuer wird, ist Mittelvolumen-Arbeit. Bei 10.000 Tasks pro Monat sind Sie schon außerhalb von Professional und zahlen für Company-Kapazität, die Sie nicht voll nutzen. Der klassische Migrations-Triggerpunkt.

Make.com: Operationen erklärt

Make.com rechnet pro Operation. Eine Operation ist eine einzelne Modul-Ausführung in einem Scenario. Jedes Modul, das läuft, zählt eine Operation — inklusive innerhalb von Iteratoren. Router und Filter selbst zählen nicht, aber Module innerhalb schon.

Derselbe 5-Schritt-Zapier-Workflow, nach Make portiert, landet üblicherweise bei 5 bis 7 Operationen pro Lauf, weil Make oft ein Extra-Modul für Datenmanipulation braucht, das Zapier in seinen Aktionsschritt bündelt.

Make.com-Pricing, 2026:

Makes Vorteil: Core bei 10,59 $ gibt 10× die Operationen für 1/3 des Preises von Zapier Starter. Der größte Einzel-Grund, warum Teams von Zapier abwandern.

Die Falle bei Make: Iteration und Error-Handling. Einen Iterator über ein 50-Item-Array triggert 50 Operationen pro nachgelagertem Modul. “Incomplete Executions”, der Retry-Mechanismus für gescheiterte Scenarios, verbraucht bei jedem Retry Operationen. Error-Handler-Branches mit eigenen Modulen zählen auch.

Budgetieren Sie 1,1× bis 1,2× Ihres gemessenen Volumens für Retries und Fehlerpfade. Wenn Ihre Scenarios in einem sauberen Monat 8.000 Operationen laufen, planen Sie 9.500 in einem echten Monat.

n8n: Executions erklärt

n8n rechnet pro Execution auf Cloud. Eine Execution ist ein vollständiger Workflow-Lauf — egal wie viele Nodes er hat. Ein 3-Node-Workflow und ein 30-Node-Workflow zählen beide als 1 Execution pro Trigger.

Das ist ein fundamental anderes Modell. Bei Zapier und Make kosten zusätzliche Schritte Geld. Bei n8n sind zusätzliche Nodes frei. Sie bezahlen nur, wie oft der Workflow feuert.

n8n-Cloud-Pricing, 2026:

Selbst gehostetes n8n ist der Ausreißer. Ein 20-€-Hetzner-VPS fährt unbegrenzte Workflows und unbegrenzte Executions. Der Haken: Sie betreiben es. Backups, Upgrades, SSL, Monitoring, Incident-Response werden alle Ihr Problem. Diese Ops-Kosten sind real — und der Hauptgrund, warum Teams trotz der Unit-Ökonomie des Self-Hostings auf n8n Cloud bleiben.

Wenn Sie schon Linux-Services produktiv betreiben, zahlt sich selbst gehostetes n8n binnen eines Monats bei jedem nennenswerten Volumen zurück. Wenn nicht, schlägt n8n Cloud Pro bei 50 € für 10.000 Executions Zapier und Make in den meisten Volumen-Bändern.

Vollständiges Setup im n8n-Self-Hosting-Leitfaden.

Weitere Plattformen kurz

Drei Plattformen tauchen häufig in RFPs auf und verdienen Erwähnung.

Zoho Flow rechnet pro Flow-Run, bei dem ein Trigger einem Lauf entspricht. Modell nah an n8ns Execution-Modell. Preise liegen zwischen Zapier und Make bei ähnlichen Volumina; die Plattform ist stärkst innerhalb des Zoho-Ecosystems (CRM, Desk, Books). Außerhalb haben Make und n8n reichere Connector-Bibliotheken.

IFTTT rechnet pro Applet-Run. Ein Trigger-Fire ist ein Lauf. IFTTT ist konsumentenorientiert, Pro-Tier ist günstig, aber die Connector-Palette für B2B-Services hinkt den drei Großen hinterher. Nützlich für Home-Automation und Social-Posting, selten passend für operative Business-Workflows.

Microsoft Power Automate rechnet pro Flow-Run in Premium-Tiers, mit Lower-Tier-Plänen inside Microsoft 365. Pricing ist enterprise-fokussiert und ohne Quote opaque. Das Killer-Feature: enge Microsoft-365- und Dynamics-Integration. Wenn Ihr Stack Microsoft-first ist, ist Power Automate der Default, und die Kostendiskussion dreht sich um Seats und Premium-Connectors, nicht Per-Run-Volumen.

Seite an Seite bei realistischem Volumen

Drei übliche Volumen-Bänder mit echten Zahlen, saubere Monat + Standard-Retry-Raten angenommen.

Kleines Team, 500 Läufe pro Monat, 3 Schritte pro Lauf (1.500 Zapier-Task-Äquivalent):

Sieger: Make. Zapier ist 7× die Kosten für dieselbe Arbeit.

Mittleres Team, 5.000 Läufe pro Monat, 5 Schritte pro Lauf (25.000 Zapier-Tasks):

Sieger: n8n selbst gehostet, wenn Sie Ops-Skills haben, Make wenn nicht. Zapier Company macht hier finanziell keinen Sinn, außer Sie brauchen Compliance-Features.

Großes Team, 50.000 Läufe pro Monat, 8 Schritte pro Lauf (400.000 Zapier-Tasks):

Sieger: n8n selbst gehostet mit Ops-Owner, oder Make Enterprise für Vendor-gemanagte Infrastruktur mit vertrautem Builder.

Versteckte Kosten, die die meisten übersehen

Fünf Kostenleaks, die auf keiner Pricing-Seite stehen.

Fehler-Retries. Zapier und Make zählen Retry-Läufe als neue Tasks oder Operationen. Ein Workflow, der eine flatternde Downstream-API trifft und dreimal retryt, kostet 4× die Happy-Path-Nutzung. 1,1× bis 1,2× für Retries in jedes Volumen-Estimate einrechnen.

Iteration innerhalb eines Schritts. Ein 20-Item-Array in Make durchzuloopen triggert 20 Operationen pro Modul im Loop. Dieselbe Iteration in einem Zapier-Multi-Step-Zap nutzt Zapiers bezahltes Looping-Feature, das als Zusatz-Tasks abgerechnet wird. Ein 20-Item-Loop mit 3 Modulen innen sind 60 Operationen in Make. Summiert sich bei täglich laufenden Scenarios schnell.

Webhook-Flooding. Ein Upstream-Service, der 10 Webhooks pro Sekunde für eine Minute feuert, sind 600 Trigger. Wenn Ihr Workflow jeden verarbeitet, sind das 600 Läufe. Am Filter rate-limiten oder ein Queue-Modul zum Debouncen davor setzen, bevor die echte Logik läuft.

Error-Handler-Branches. In Make zählen Module innerhalb eines Error-Handler-Routes als Operationen. Teams fügen oft großzügiges Error-Handling hinzu, das die Operation-Anzahl pro Scenario still verdoppelt. Fehlerpfade schlank halten — zu einem externen Service loggen statt fünf Make-Module für eine Mail-Formatierung einzubauen.

Geplantes Polling. Ein Polling-Trigger alle 5 Minuten sind 8.640 Trigger-Fires pro Monat — bevor überhaupt ein Aktionsschritt läuft. Wo möglich Webhook-Trigger oder Push-basierte APIs nutzen. Polling ist die größte stille Kostenquelle auf Make und Zapier.

Derselbe Workflow, drei Plattformen, echte Zahlen

Ein konkretes Beispiel, das ständig hochkommt: Shopify-Order-Processing mit Klaviyo-Enrichment.

Die Logik: Neuer Shopify-Order feuert den Trigger, Kunden von Klaviyo holen, nach VIP-Status branchen. Wenn VIP: Airtable-Record anlegen und Slack-Alert senden. Wenn nicht: nur Airtable-Record.

Bei 1.000 Orders pro Monat:

Derselbe Workflow, dasselbe Volumen, 13× Preisdifferenz zwischen den Extremen. Die Wahl zwischen Make und n8n hier ist Präferenz. Make hat die bessere UI für Business-User. n8n hat die besseren Primitiven für Engineers, die ihre Automatisierung in Git versionieren wollen.

Für einen vollen Builder-Vergleich siehe Make vs. n8n für produktive Workloads und den DACH-Walkthrough Make vs. n8n Vergleich.

Migrations-Taktiken, wenn das Pricing reißt

Drei Migrationspfade decken die meisten realen Fälle ab.

Zapier zu Make ist der häufigste erste Schritt. Typische Ersparnis bei 1.000+ Tasks pro Monat: 60 bis 80 Prozent. Die Workflows portieren recht sauber, weil beide visuelle Builder mit ähnlichen Modul-Konzepten sind. Planen Sie zwei bis drei Tage Re-Wiring pro signifikantem Zap, weniger bei unter zehn Workflows. Voller Walkthrough: Zapier zu Make migrieren.

Make zu n8n selbst gehostet ist der zweite Sprung. Ersparnisse bei 10.000+ Operationen pro Monat: 80 bis 95 Prozent direkte Plattformkosten, gegengerechnet mit VPS und Ops-Zeit. Richtiger Move, wenn Sie Linux produktiv fahren und JSON-definierte Workflows unter Git haben wollen.

Zapier direkt zu n8n ist der größte mentale Shift. Wechsel von reinem visuellen SaaS zu einem Builder, der Code zugänglich macht, auf Ihrer Infrastruktur läuft (wenn Sie wollen) und sehr anders zählt. Ersparnisse sind riesig, aber die Lernkurve steiler. Step-by-Step: Zapier zu n8n migrieren.

Pricing-agnostische Empfehlungen:

1. Mit der Plattform starten, die Ihren Use Case im Free- oder niedrigsten Paid-Tier abdeckt
2. Läufe und Schritte monatlich messen, nicht quartalsweise
3. Migration planen, wenn Sie 2× die Free- oder Starter-Tier-Nutzung erreichen
4. At Scale ist selbst gehostetes n8n fast immer die niedrigste Plattform-Kostenposition — aber Ops-Zeit ist ein echter Posten

Wann Enterprise-Pricing sich lohnt

Enterprise-Tiers sind nicht für Volumen gepreist. Sie sind für Compliance, Support und Planbarkeit gepreist.

Vier Signale, dass Enterprise-Tier die richtige Wahl ist — unabhängig von der Kostenrechnung:

• Audit-Log- oder SOC2-Anforderung. Wenn Ihr Compliance-Team einen Audit-Trail braucht, wer wann welche Automatisierung geändert hat, sind Enterprise-Tiers der sauberste Weg.
• SLA-gestützte Uptime. Wenn ein Automatisierungs-Failure echten Umsatz kostet (Payments, Order-Fulfillment, Trading-Signale), ist ein vertraglich geregeltes SLA den Aufpreis wert.
• Dedizierter Support. Wenn ein Kern-Workflow um 3 Uhr morgens kaputtgeht, zählt ein Support-Kontakt, der Ihren Account kennt, mehr als der Unit-Preis.
• Volumen-Commit für Planbarkeit. Finance bevorzugt oft ein flaches Jahres-Commit gegenüber variabler Per-Run-Abrechnung — selbst wenn die variable Option in den meisten Monaten günstiger wäre.

Wenn keines dieser Signale zutrifft, ist der Enterprise-Tier meist Überausgabe. Auf Core oder Pro bauen, wenn möglich selbst hosten, und Compliance kaufen, wenn Compliance tatsächlich das ist, was Sie brauchen.

Entscheidungs-Framework nach Volumen

Eine Spickzettel für den 90-%-Fall:

Zwei Querschnitte zur Tabelle:

• Wenn Sie die absolut schnellste Time-to-First-Working-Zap wollen und unter 2.000 Tasks pro Monat sind, gewinnt Zapier bei Geschwindigkeit, auch wenn es bei Unit-Kosten verliert.
• Wenn Sie einen Engineer haben, der bereits Linux-Services produktiv betreibt, ist selbst gehostetes n8n der Default ab 2.500+ Läufen pro Monat.

Automatisierungs-Pricing hört auf verwirrend zu wirken, sobald Sie aufhören, Listenpreise zu vergleichen, und anfangen, Ihren tatsächlichen Workflow bei Ihrem tatsächlichen Volumen zu vergleichen. Schritte zählen, Retries zählen, Polling zählen — und die richtige Plattform wird offensichtlich.

Weiterführendes

• Make vs. n8n für produktive Workloads
• Zapier zu Make migrieren
• Zapier zu n8n migrieren
• Make vs. n8n Vergleich
• n8n-Self-Hosting-Leitfaden