Zapier vs Make vs n8n (2026): Pricing, True Cost at Scale, and What Breaks in Production

Last tested: July 2026

Every automation platform counts usage differently, and that is not an accident. Zapier charges per task, Make.com charges per operation, n8n charges per execution. Those three words look interchangeable on a pricing page. They are not. The same workflow can cost $208 on Zapier, $20 on Make, or the price of a VPS on self-hosted n8n.

This guide is a practitioner walkthrough of how each platform counts, where the hidden costs hide, and which platform actually wins at each volume band. I run production workflows on Make and n8n for my own products (Teedian, a content operations engine), so the examples below reflect real wiring, not marketing math.

The short verdict: under 500 runs a month almost any free tier works. Between 500 and 5,000 runs a month, Make.com Core is the sweet spot. Above 5,000 runs, self-hosted n8n almost always wins if you have the ops capacity. Zapier is rarely the cost winner past the Starter tier, but it is frequently the fastest to ship.

Why pricing comparisons are hard

Three reasons pricing comparisons across automation platforms almost always mislead.

First, the units are different. A Zapier “task” is an action step. A Make “operation” is a module execution. An n8n “execution” is a full workflow run. If you run the same logic on all three, Zapier counts it four times, Make counts it six times, n8n counts it once.

Second, loops, filters, and error handlers count differently on each platform. Make counts every iteration inside a loop, and counts branches inside an error handler. Zapier counts paths as separate multi-step features. n8n does not care how many nodes you have, it only cares how many times the workflow ran.

Third, retries and polling silently inflate bills. If a run fails and retries three times, that is 3x the usage on Zapier and Make, and 3x the execution count on n8n Cloud. Polling triggers, where the platform checks an API every few minutes, can blow a quota before any real work happens.

You cannot compare sticker prices. You have to compare the same workflow, measured at the same realistic volume, with retries and error paths included.

Zapier: tasks explained

Zapier charges per task. A task is any successful action step inside a Zap. The trigger does not count. Every subsequent step does.

A 5-step Zap that fires 100 times per month consumes 400 tasks, because the trigger is free and the four action steps each count once per run. A 10-step Zap that fires 100 times consumes 900 tasks. Paths, filters, and iteration features multiply this further.

Current Zapier pricing, 2026:

The jump from Professional to Company is 25x the task allotment but only 2.8x the price, so the per-task cost drops sharply if you actually use all 50,000. Most Company-tier buyers pay for compliance, not volume.

Where Zapier gets expensive fast is middle-volume work. At 10,000 tasks a month you are already outside Professional and paying for Company capacity you will not fully use. This is the classic migration trigger point.

Make.com: operations explained

Make.com charges per operation. An operation is a single module execution inside a scenario. Every module that runs counts one operation, including inside iterators. Routers and filters themselves do not count, but modules inside them do.

The same 5-step Zapier workflow ported to Make usually lands at 5 to 7 operations per run, because Make often needs an extra module for data shaping that Zapier bundles into its action step.

Make.com pricing, 2026:

Make’s advantage is that Core at $10.59 unlocks 10x the operations for 1/3 the price of Zapier Starter. That is the single biggest reason teams migrate off Zapier.

The trap with Make is iteration and error handling. Looping an iterator over a 50-item array triggers 50 operations per downstream module. “Incomplete executions,” the retry mechanism that re-runs failed scenarios, consumes operations each time. Error handler branches with their own modules also count.

Budget 1.1x to 1.2x your measured volume for retries and error paths. If your scenarios run 8,000 operations in a clean month, plan for 9,500 in a real month.

n8n: executions explained

n8n charges per execution on Cloud. An execution is one complete workflow run, regardless of how many nodes it has. A 3-node workflow and a 30-node workflow both count as 1 execution per trigger.

This is a fundamentally different model. On Zapier and Make, adding steps costs money. On n8n, adding nodes is free. You pay only for how often the workflow fires.

n8n Cloud pricing, 2026:

Self-hosted n8n is the outlier. A €20 Hetzner VPS runs unlimited workflows and unlimited executions. The catch is you operate it. Backups, upgrades, SSL, monitoring, incident response all become your problem. That ops cost is real, and it is the main reason teams stay on n8n Cloud despite the unit economics of self-hosting.

If you already run Linux services in production, self-hosted n8n pays back within a month at any meaningful volume. If you do not, n8n Cloud Pro at €50 for 10,000 executions still beats Zapier and Make at most volumes.

For the full setup walkthrough see the n8n self-hosting guide.

Other platforms briefly

Three more platforms come up in RFPs often enough to cover.

Zoho Flow charges per flow run, where one trigger equals one run. The counting model is close to n8n’s execution model. Pricing sits between Zapier and Make at similar volumes, and the platform is strongest inside the Zoho ecosystem (CRM, Desk, Books). Outside that ecosystem, Make and n8n have richer connector libraries.

IFTTT charges per applet run. One trigger fire equals one run. IFTTT is consumer-leaning, and the Pro tier is inexpensive, but the connector set for B2B services lags the big three. Useful for home automation and social posting, rarely a fit for operational business workflows.

Microsoft Power Automate charges per flow run in the premium tiers, with lower-tier plans included inside Microsoft 365. The pricing is enterprise-focused and opaque without a quote. The killer feature is tight Microsoft 365 and Dynamics integration. If your stack is Microsoft-first, Power Automate is the default and the cost conversation is about seats and premium connectors, not per-run volume.

Side-by-side at realistic volumes

Three common volume bands with real numbers, assuming a clean month with standard retry rates.

Small team, 500 runs per month, 3 steps each (1,500 Zapier tasks equivalent):

Winner: Make. Zapier is 7x the cost for the same work.

Mid team, 5,000 runs per month, 5 steps each (25,000 Zapier tasks):

Winner: n8n self-hosted if you have the ops skills, Make if you do not. Zapier Company makes no financial sense here unless you need compliance features.

Large team, 50,000 runs per month, 8 steps each (400,000 Zapier tasks):

Winner: n8n self-hosted with an ops owner, or Make Enterprise if you want vendor-managed infrastructure with a familiar builder.

Hidden costs most people miss

Five cost leaks that do not show up on the pricing page.

Error retries. Zapier and Make count retried runs as new tasks or operations. A workflow that hits a flaky downstream API and retries three times costs 4x the happy-path usage. Budget 1.1x to 1.2x for retries in any volume estimate.

Iteration inside a step. Looping over a 20-item array in Make triggers 20 operations for each module inside the loop. The same iteration inside a Zapier multi-step Zap uses Zapier’s paid looping feature, which gets billed as additional tasks. A 20-item loop with 3 modules inside is 60 operations in Make. That adds up fast on daily-running scenarios.

Webhook flooding. An upstream service that fires 10 webhooks per second for a minute is 600 triggers. If your workflow processes each one, that is 600 runs. Rate-limit at the filter or use a queue module to debounce before the real logic runs.

Error handler branches. In Make, modules inside an error handler route count as operations. Teams often add generous error handling that silently doubles the operation count per scenario. Keep error paths lean, and log to an external service rather than adding five Make modules to format an email.

Scheduled polling. A polling trigger that runs every 5 minutes is 8,640 trigger fires per month before any action step runs. Where possible, use webhook triggers or push-based APIs. Polling is the single biggest quiet cost on Make and Zapier.

Same workflow, three platforms, real numbers

A concrete example that comes up constantly: Shopify order processing with Klaviyo enrichment.

The logic: new Shopify order fires the trigger, fetch the customer from Klaviyo, branch on VIP status. If VIP, create an Airtable record and send a Slack alert. If not, just create the Airtable record.

At 1,000 orders per month:

Same workflow, same volume, 13x price difference between the extremes. The choice between Make and n8n here is a preference call. Make has the better UI for business users. n8n has the better primitives for engineers who want to version-control their automation.

For a full builder comparison see the production sections below and the German walkthrough Make vs n8n Vergleich.

Migration tactics when pricing breaks

Three migration paths cover most real situations.

Zapier to Make is the most common first move. Typical savings at 1,000+ tasks per month are 60 to 80 percent. The workflows port fairly cleanly because both are visual builders with similar module concepts. Plan for two to three days of re-wiring per significant Zap, less if you have fewer than ten workflows. Full walkthrough in migrate Zapier to Make.

Make to n8n self-hosted is the second jump. Savings at 10,000+ operations per month are 80 to 95 percent in direct platform cost, offset by VPS and ops time. This is the right move when you already run Linux in production and want JSON-defined workflows under Git.

Zapier direct to n8n is the biggest mental shift. You move from a pure visual SaaS to a builder that exposes code, runs on your infrastructure if you want, and counts very differently. Savings are huge but the learning curve is steeper. The step-by-step is in migrate Zapier to n8n.

Pricing-agnostic advice:

1. Start with the platform that covers your use case at the free or lowest paid tier
2. Measure runs and steps monthly, not quarterly
3. Plan migration when you hit 2x the free or starter tier usage
4. At scale, self-hosted n8n is almost always the lowest platform cost, but ops time is a real line item

When enterprise pricing is worth it

Enterprise tiers are not priced for volume. They are priced for compliance, support, and predictability.

Four signals that the enterprise tier is the right call regardless of cost math:

• Audit log or SOC2 requirement. If your compliance team needs an audit trail of who changed which automation when, enterprise tiers are the cleanest way to get it.
• SLA-backed uptime. If an automation failure costs real revenue (payments, order fulfillment, trading signals), a contractual SLA is worth the premium.
• Dedicated support. When a core workflow breaks at 3am, a support contact who knows your account matters more than unit price.
• Volume commit for predictability. Finance often prefers a flat annual commit over variable per-run billing, even if the variable option would be cheaper in most months.

If none of those signals apply, the enterprise tier is usually overspending. Build on Core or Pro, self-host if you can, and buy compliance when compliance is actually what you need.

Decision framework by volume

A cheat sheet for the 90 percent case:

Two crosscuts on top of the table:

• If you want the absolute fastest time to first working Zap and you are under 2,000 tasks per month, Zapier wins on speed even if it loses on unit cost.
• If you have an engineer who already runs Linux services in production, self-hosted n8n is the default at any volume over 2,500 runs per month.

Automation pricing stops looking confusing once you stop comparing sticker prices and start comparing your actual workflow at your actual volume. Count the steps, count the retries, count the polling, and the right platform becomes obvious.

What breaks first in production

Pricing tells you which platform is cheapest. Production tells you which one holds up. I run both Make.com and n8n in production for clients. Content pipelines, data enrichment flows, CRM sync jobs, AI agent orchestration. Some of these run thousands of executions per week. Here is what actually matters when you move past the tutorial phase.

The core difference behind that table: Make.com is a managed platform. n8n is infrastructure you own. That sounds obvious, but the implications hit you at 2 AM when something breaks. With Make.com, their team handles uptime, scaling, and security patches. With n8n, that is your job or your client’s job. This is not a quality judgment. It is an architecture decision. And it should be the first thing you decide, not the last.

If you are deciding this for a team rather than a single workflow, frame it as build-vs-buy. Make.com is buy: predictable per-seat and per-operation cost, no ops burden, data on their servers. n8n self-hosted is build: near-zero marginal cost at volume, full data residency in your VPC, and an ops responsibility someone has to own. The break-even is rarely the sticker price; it is whether you have the ops capacity to run n8n reliably. For regulated or EU data-residency cases the generative AI for business in DACH guide covers where self-hosting becomes non-negotiable.

Where Make.com holds up: webhooks, debugging, error handling

Webhook reliability. Make.com’s webhook infrastructure is battle-tested. Webhooks queue automatically when a scenario is paused or rate-limited. I have seen Make.com webhook queues hold thousands of events during a downstream API outage and process them cleanly once the scenario resumed. n8n webhooks are tied to your instance. If your n8n server goes down, those webhooks are gone. You need to build your own queue layer (Redis, a message broker, or a reverse proxy with retry logic) to get the same reliability.

Visual debugging at scale. When a scenario fails at step 14 of 23, Make.com shows you the exact data at every step. You click through the execution history, see what went in, what came out, where it broke. For clients who need to debug their own workflows, this is genuinely hard to replicate. n8n has execution logs, but the debugging experience for complex multi-branch workflows is rougher. You spend more time in logs and less time in visual inspection.

Error handling patterns. Make.com’s error handler routes (break, resume, ignore, rollback) are a first-class feature. You attach an error handler to any module and define exactly what happens. This matters enormously in production because every API call can fail, and your workflow needs to handle that gracefully. n8n has try/catch via the Error Trigger node, but it is workflow-level, not node-level. Fine-grained error handling requires more wiring.

Where n8n holds up: code, data residency, version control

Code when you need it. n8n lets you drop into JavaScript (or Python) at any node. When the visual builder is not enough, you write a Function node and move on. Make.com has no equivalent. You are limited to what their modules expose. When you need custom logic, you call an external API or a webhook to a separate service. This adds latency, complexity, and another failure point.

Data stays on your infrastructure. Self-hosted n8n means your data never leaves your infrastructure. For clients in healthcare, finance, or anything GDPR-sensitive, this can be a hard requirement, not a preference. Make.com processes data on their servers. They are SOC 2 compliant and EU-hosted options exist, but for some compliance frameworks, “our data stays on our servers” is the only acceptable answer. The n8n self-hosting guide walks through the VPS setup, reverse proxy, and backup strategy I use with clients.

Git-based version control. n8n workflows are JSON files. You can commit them to git, diff changes, roll back, review in a PR. This is how software teams work. Make.com blueprints can be exported as JSON, but the round-trip is not clean. The JSON is verbose, IDs change on import, and there is no built-in version control. In practice, you end up with “scenario copy (3)” instead of a proper changelog.

Make vs n8n for AI agent workflows

Both platforms now support AI agent workflows. This is where I spend most of my time with clients, so here is the honest take.

Make.com + AI: Works well for linear AI pipelines. Input goes in, LLM processes it, output goes somewhere. The HTTP module calls any API. But orchestrating multi-step agent behavior (where the next step depends on the AI’s output) gets awkward fast in a visual builder.

n8n + AI: The LangChain nodes and AI Agent node give you more native agent patterns. Tool use, memory, chain-of-thought routing. If your workflow is “AI decides what to do next,” n8n handles this more naturally.

Neither platform is great for complex agent orchestration. At a certain point, you need code. But if you are building AI-augmented workflows (not fully autonomous agents), both work.

Production checklist: which platform survives your workload

I use this with every client:

Choose Make.com when:

• The team is non-technical and needs to maintain workflows themselves
• Webhook reliability is critical and you do not want to manage infrastructure
• The workflow is primarily API-to-API data movement
• You need production-grade error handling without custom code

Choose n8n (self-hosted) when:

• Cost at scale matters (high-volume processing)
• You need custom code in the workflow
• Data must stay on your infrastructure
• You want git-based version control and CI/CD for your automations
• The team has engineering capacity to maintain infrastructure

Choose neither when:

• The workflow is complex enough to justify a proper codebase
• You need sub-second latency
• The automation is core to the product, not a supporting process

That last point is important. Both Make.com and n8n are excellent for operational automation. They are not application backends. When clients ask me to build their core product logic in Make.com, I push back.

One closing caveat from running both: the platform matters less than the architecture. I have seen well-designed Make.com setups outperform sloppy n8n deployments, and vice versa. What matters is: error handling at every step, idempotent operations, monitoring and alerting, clean separation between workflows, and knowing when to stop using a visual builder and write code instead.

Changelog

• 2026-07-11: merged the Make vs n8n production-workloads guide into this page; added production reliability sections.