n8n Executions vs Make Credits: How Usage Is Counted

What n8n Executions, Make Operations, and Make Credits Actually Measure

An n8n execution is a single run of an entire workflow. Only production executions, meaning runs started automatically by a trigger, schedule, or polling node, count toward a paid plan’s execution quota. According to n8n’s documentation on understanding executions, a workflow with two nodes and a workflow with forty nodes both count as one execution if each runs once. The unit tracks how many times a workflow started, not how much work happened inside it.

A Make operation is different in kind. Per Make’s operations guide, an operation is a single module run that processes data or checks for new data, and most action modules generate one operation per bundle they process. A credit is the commercial unit Make bills against; Make’s credits-and-operations overview describes credits and operations as related but distinct, with credits representing what a customer pays for the operations a scenario performs.

Where Each Platform Places the Counting Boundary

n8n draws its boundary around the workflow run as a whole. A pricing page built around this idea states that an execution is a single run of an entire workflow regardless of how many steps it contains or how much data it processes. That means adding nodes, branches, or loops inside one production run does not, by itself, add executions. What changes the execution count is how many times the workflow starts: how often a schedule fires, how many webhook requests arrive, or how many polling checks return new data. MetaFlowKit’s n8n platform hub covers this counting model alongside the rest of n8n’s execution and hosting behavior.

Make draws its boundary around the module, not the scenario. Modules run to process or check data, and a single scenario run can accumulate many operations if several ordinary action modules each touch multiple bundles. The trigger module is a documented exception to per-bundle multiplication: it runs once per scenario execution to check for or retrieve data and generates one operation regardless of how many bundles it returns. Search, aggregator, iterator, and no-credit flow-control modules also have their own current credit rules, so only ordinary downstream actions should be modeled as one credit per processed input bundle. See MetaFlowKit’s Make platform hub and the dedicated How Make Operations Work guide for a fuller bundle-by-bundle walkthrough.

This structural difference is why the two units cannot be converted with a single multiplier. The ratio between an n8n execution total and a Make operation total depends on how many modules sit downstream of the trigger and how many bundles each one processes, which varies scenario by scenario; MetaFlowKit’s Automation Usage Calculator can model a specific workload rather than relying on a fixed ratio.

Primary Model: One Trigger Event, Ten Records in a Batch

Assume a single production trigger event delivers ten records in one run, and two ordinary record-level action modules process each record afterward. Every structural assumption below must hold for the arithmetic to apply.

Second Model: Ten Separate Trigger Events, One Record Each

Now assume the same ten records arrive as ten separate external trigger events, each carrying one record through the same two ordinary actions.

The two models use the same ten records and the same two downstream actions, yet the n8n total moves by 10x (1 to 10) while the Make total moves by roughly 43% (21 to 30). Changing how records arrive, batched in one event or split into many, changes both totals, but it changes them by different amounts because the platforms count at different boundaries. Neither platform automatically converts many small external events into one large batch; that behavior has to be built deliberately, usually with a queue, a scheduled poll, or an aggregation step ahead of the trigger.

How Polling, Manual Runs, Sub-Workflows, Filters, and Routers Affect the Count

Several documented behaviors change one side of the comparison without changing the other, and conflating them is a common source of bad estimates.

Polling and no-data checks. An n8n polling trigger, such as a Google Drive or database poll, only counts as a production execution when it finds new data; n8n’s types-of-executions documentation confirms polls that return no results do not count. A Make trigger module behaves differently: it consumes one operation per check under the ordinary trigger rule, whether or not the check returns new data. A high-frequency polling trigger with mostly empty checks can accumulate Make operations while contributing zero n8n executions.

Manual runs. Manual executions, run from the n8n editor while building or testing, are excluded from the paid-plan execution quota entirely. Make has no equivalent blanket exemption in the sources reviewed here; treat manual Make test runs as a cost to verify separately rather than assuming parity with n8n.

Sub-workflows. Per n8n’s guide to breaking workflows into smaller parts, sub-workflow executions do not count toward a plan’s monthly execution or active-workflow limits; only the parent, top-level execution counts. This makes modular n8n design attractive for organizing logic, though it should not be read as a reason to split workflows purely to dodge quota limits, since the underlying compute and downstream calls still run.

Filters and routers. In n8n, conditional branches inside a single root execution do not by themselves add plan executions; the run stays one execution regardless of how many branches it evaluates. Separate root workflows, triggered independently, are what create additional execution boundaries. Make’s current credit guide lists routers and filters as no-credit modules. They can direct or stop bundles without consuming credits themselves, but ordinary downstream actions on every route that actually runs still consume credits for the bundles they process.

Why a Lower Unit Count Is Not Automatically a Lower Cost

Comparing raw totals like 1 execution versus 21 operations invites the conclusion that n8n is simply cheaper for this workload. That conclusion does not follow from unit counts alone. Plan prices, included allowances, and per-unit rates differ across n8n, Make, and the specific tier a team is on, so a small execution allowance and a large credit allowance are not directly comparable in isolation. This article compares what is counted, not what a subscription costs.

There is also an inverse risk worth naming: a single n8n execution can still involve substantial compute time, memory, API calls, or third-party service charges, even though it remains exactly one plan execution. A workflow that loops internally over thousands of items may be light on quota but heavy on runtime and external API costs. Unit totals describe billing meters, not infrastructure load.

Workload-Shape Decision Matrix

The general pattern: n8n’s execution meter rewards consolidating many records into fewer, larger production runs. Make’s meter is sensitive to both scenario-run frequency and the number of bundles ordinary downstream modules process; batching can reduce repeated trigger checks without removing the downstream per-bundle work.

Common Comparison Mistakes

• Treating one n8n execution as equivalent to one Make operation, when they measure different things.
• Assuming a fixed conversion ratio that ignores trigger boundaries, module count, and bundle count.
• Counting n8n nodes as separate executions instead of counting how many times the workflow started.
• Assuming every Make module always costs one credit, ignoring dynamic AI features and Make Code’s rate.
• Generalizing n8n’s paid-plan execution quota to self-hosted Community Edition, which does not use that same billed execution quota.

Verification and Reconciliation

Treat n8n’s execution list and usage view, and Make’s scenario history and credit history, as the source of truth for actual usage; the models above are planning estimates, not substitutes for checking a real account.

1. Pick a shared date window that covers the same business activity on both platforms.
2. In n8n, open the workflow’s Executions list and filter by execution start time to count production runs in that window.
3. In Make, open scenario history for the equivalent scenario and review the operations bubble shown above each module for the same window.
4. Match totals against the structural model you built (batch size, event count, modules per run) and note any gap.
5. Investigate gaps by checking for polling checks with no new data, manual test runs, retried steps, or AI/Code modules with variable rates before assuming the model is wrong.

• Confirm which trigger type is in use, since polling, schedule, and webhook triggers count differently in n8n.
• Confirm whether any Make module uses a nonstandard credit rule, including dynamic AI usage or Make Code’s runtime-based rate.
• Confirm the date window is identical on both platforms before comparing totals.

Frequently Asked Questions

Does adding more nodes to an n8n workflow increase execution usage?

No. An execution is counted per run of the workflow, not per node. A workflow with five nodes and one with fifty both count as one execution per production run.

Does a Make trigger that finds no new data still cost anything?

Under the ordinary trigger rule, a scheduled Make trigger module consumes one credit per run or check, whether or not it returns new data. This differs from an n8n polling trigger, which only counts an execution when it finds new data.

Can I convert Make credits into an equivalent number of n8n executions?

Not with a fixed ratio. The conversion depends on how many modules run downstream of the trigger and how many bundles each one processes in your specific scenario, which varies by workflow design.

Does self-hosted n8n Community Edition use the same execution quota as paid plans?

No. The paid-plan execution quota applies to n8n Cloud and licensed self-hosted plans. Self-hosted Community Edition does not carry that same billed execution quota, though it still has real infrastructure and any external API costs to account for separately.

Are sub-workflow executions counted separately in n8n?

Documented sub-workflow executions do not count toward the parent plan’s execution or active-workflow limits; only the parent, top-level execution counts.