Build log: an n8n admission gate that refuses noisy triggers in 2026

This guide is assembled from official documentation and vendor pricing pages — we did not run this build ourselves. Every price, limit and node setting links to the page it came from, read on 2026-11-02.

Why an admission gate matters on n8n’s billing model

An admission gate is a design pattern in which a workflow refuses noisy, duplicate, or out-of-scope triggers before the expensive half — API calls, LLM nodes, enrichment, writes — ever runs, so you spend fewer of your quota’s executions and send fewer useless alerts. On n8n this matters more than on per-task tools, because n8n’s pricing page defines the billed unit at the whole-workflow level: “An execution is a single run of your entire workflow. It doesn’t matter how many steps are in the workflow or how much data it processes. It’s still a single execution.” The page adds that “n8n lets you build freely and only pay when a workflow runs from start to finish.” Once a run starts, every node inside it is included; the run itself costs one execution. The only cost lever is how many runs start, which is exactly what an admission gate controls.

One honest-methodology note first, repeated at the end: this guide is assembled from official n8n documentation and vendor pricing pages; nothing in it was run hands-on. Every configuration value below comes from those docs, and every figure is the one printed on the linked page.

What n8n’s quotas actually buy (and how Zapier and Make differ)

n8n’s cloud plans price whole executions, Zapier prices individual tasks, and Make credits actions — three different units that make direct price comparison misleading without restating what each unit covers. From the source pages:

n8n Starter is $20/mo billed annually for 2,500 workflow executions, unlimited steps, and 5 concurrent executions; max execution duration is 5 minutes and max saved executions are 2,500. Pro is $50/mo billed annually for 10,000 executions, up to 50 concurrent, 40-minute max duration, and 25,000 saved executions. Business is 667 EUR/mo billed annually for 40,000 executions, a self-hosted licence, queue mode, and SSO/LDAP. Enterprise is custom with 200+ concurrent. (n8n pricing)
Zapier defines tasks per Zap run, and its pricing page states that “AI steps, code, and SDK now all follow the same task-based pricing model.” Free is $0/month at 100 tasks/month with two-step Zaps and 15-minute polling; Professional starts from $19.99/month; Team starts from $69/month for 25 users; task tiers run from 100 up to 2M tasks/month. (Zapier pricing)
Make states: “As of August 27, credits are the billing unit in Make. Each action your scenario performs consumes a certain number of credits - most actions consume 1 credit.” Notably, the Router module consumes no credits, and error handler modules (Rollback, Break, Resume, Commit, Ignore) consume no credits. The free plan includes 1,000 credits/month. (Make pricing)

Arithmetic, not measurement

The following is arithmetic, not measurement — it is list price divided by quota, with the inputs shown:

Starter: $20 ÷ 2,500 executions = $0.008 per execution
Pro: $50 ÷ 10,000 executions = $0.005 per execution

These are list-price ceilings assuming you use the full quota; they are not measured costs, and overage fees are capped on Starter and Pro per n8n’s pricing page.

What you pay for	n8n	Zapier	Make
Billing unit	Workflow executions	Tasks	Credits
What one unit covers	“A single run of your entire workflow,” regardless of steps or data volume	Each task an action performs, including AI steps, code, and SDK	“Each action your scenario performs” — most actions consume 1 credit
Cheapest published entry point	Starter $20/mo billed annually, 2,500 executions	Free: 100 tasks/month; Professional from $19.99/month	Free: 1,000 credits/month
Steps/modules that consume nothing	Unlimited steps per execution — every node inside a run is included	Not stated in the source page	Router and error handler modules (Rollback, Break, Resume, Commit, Ignore) consume no credits

If you are moving off a per-task or per-credit tool, the unit shift is the first thing to internalise; for the Make-specific steps, see our Make to n8n migration guide. And if you’re weighing a big agent against a plain workflow, our agent or workflow cost decision guide works through that choice.

The noise inventory: what fires your workflow, and should the gate refuse it?

Before building the gate, list every trigger in the workflow, what fires it, and whether the gate should refuse it — each firing is a billed execution whether or not anything useful happens.

Trigger	What fires it	Should the gate refuse it?
Email/app poll or webhook	Every new message, mention, or event	Yes, unless the sender/label is on the allowlist
Schedule-based checks	The clock, even when nothing changed	Yes, if the check can be narrowed at the source (better query, better label filter)
Sub-workflow calls	Parent workflows calling in	Only if the caller should have filtered first
Error-triggered reruns	Failed upstream runs retrying	Legitimate, but unbounded retries compound billing — see our what retries cost breakdown

Design the gate to refuse before the expensive branch: put the prefilter, allowlist and duplicate suppression upstream of any LLM node, paid API call, enrichment lookup or write. A run refused at node 3 still counts as one execution — but it costs milliseconds instead of dollars’ worth of API calls, and it never pages a human.

Stage 1: the trigger-side prefilter

Narrow the trigger itself — better labels, queries, or filters at the source — so fewer runs start at all, because the cheapest execution is the one that never begins. It is the stage easiest to skip, because filtering downstream still starts a run for every event: the refused items save downstream work, not the run itself. If your source system supports a query (a Gmail label, a saved search, a filtered feed), push the filter to the source. Re-examining what a trigger really needs to pass through is also the main lesson of our rebuilding-a-Zapier-Zap-in-n8n build log.

Stage 2: the allowlist with a Filter node

The Filter node passes items that meet a condition and omits the rest, which suits an allowlist where one combined rule set will do. Per the Filter node docs, conditions can be combined with AND or OR — but “You can’t create a mix of AND and OR rules.” If your allowlist logic genuinely needs mixed grouping (“sender is X AND subject contains Y, OR label is Z”), split it across two chained Filter nodes or use the IF node, which has true and false outputs and supports AND and OR; more than two outputs requires the Switch node. Available string operators include contains, does not contain, starts with, matches regex and does not match regex, plus the options Ignore Case and Less Strict Type Validation.

One warning the docs make explicit: the data panel’s visual filtering is “purely visual: n8n doesn’t change or delete data” and resets when the node is reopened — you must build an actual Filter node for real refusal, per the filter-out-unwanted-data guide.

Stage 3: duplicate suppression with Remove Duplicates

The Remove Duplicates node, set to “Remove Items Processed in Previous Executions,” drops items the workflow has already seen, using a history that persists between runs. The node’s docs describe three operations; the one you want is configured as:

Keep Items Where: Value Is New (the other options are Value Is Higher than Any Previous Value and Value Is a Date Later than Any Previous Date)
Value to Dedupe On: per the docs, “When using Value Is New, this must be an input field or combination of fields with a unique ID” — a message ID, an event ID, a commit SHA. Never dedupe on a mutable field such as a subject line (people edit subjects) or a timestamp (two distinct events can share one). A mutable dedupe key either suppresses legitimately-new items or lets duplicates through, and both failures are silent.
Scope: Node (default) or Workflow. Node scope means only this node’s history applies; Workflow scope shares dedupe state across the workflow. Choose deliberately: Workflow scope stops a duplicate slipping through a second branch, Node scope keeps history smaller and isolated.
History Size: available with Value Is New; “By default, n8n stores 10,000 items.” If daily volume exceeds that, old IDs roll out of history and duplicates can reappear.

The node was overhauled in n8n 1.64.0; templates and examples show starting shapes.

Clearing history is a separate operation: the third operation, Clear Deduplication History (mode Clean Database), does not touch the current input. If you change your dedupe field or need to reprocess something, you must run a clear deliberately — editing the node’s config doesn’t wipe history.

Stage 4: silence unless a human must act

The last stage is a rule, not a node: stay silent when the answer is “nothing to do.” Three documented mechanisms:

Wait node for batching and pausing. It “pauses the workflow and offloads execution data to the database,” resuming on interval, specified time, webhook call, or form submission, and $execution.resumeUrl is unique per execution. Note the boundary in the Wait node docs: “For wait times less than 65 seconds, the workflow doesn’t offload execution data to the database.” Use it to collect a batch before one notification instead of alerting per item.
Error workflow for real failures: attach one in the workflow settings and build it with the Error Trigger node; the flow-logic docs cover Stop And Error plus Error Trigger as the error-handling pair. Failures are the one thing a human must hear about.
No-op exits. If zero items survive the allowlist and dedupe, end the workflow quietly. A refused run is cheap; a refused run that also pings Slack is noise you built yourself.

Execution hygiene: keeping the cost model honest

A gate only pays off if your execution settings don’t quietly inflate or hide the numbers, so set save-on-success, pruning, and concurrency deliberately:

Save on success: EXECUTIONS_DATA_SAVE_ON_SUCCESS defaults to all; set it to none to stop saving successful runs and keep the execution list readable. Per-workflow toggles for successful, failed and manual saves live in the workflow settings, where saving execution progress “may increase latency.”
Pruning: enabled by default, on age (default 336 hours = 14 days) or count (default 10,000), per the execution data docs. New/running/waiting executions aren’t eligible, annotated executions are never pruned, and there’s a 1-hour hard-delete buffer. On SQLite, space is reused not freed unless DB_SQLITE_VACUUM_ON_STARTUP is set.
Timeouts and concurrency: EXECUTIONS_TIMEOUT defaults to -1 with EXECUTIONS_TIMEOUT_MAX at 3600 s, and Cloud Starter caps duration at 5 minutes regardless; N8N_CONCURRENCY_PRODUCTION_LIMIT defaults to -1 (unlimited) — the concurrency docs cover capping it, and Cloud plans include 5 concurrent on Starter rising to 50 on Pro.
Autodeactivation: N8N_WORKFLOW_AUTODEACTIVATION_ENABLED defaults to false; when enabled, N8N_WORKFLOW_AUTODEACTIVATION_MAX_LAST_EXECUTIONS is 3 — three crashed executions unpublish the workflow. Worth enabling so a broken trigger doesn’t burn quota in a crash loop.
Sub-workflows: the Execute Workflow node runs another workflow on the same host, with modes “run once with all items” or “once per item,” an optional “Wait for Sub-Workflow Completion,” and the sub-workflow’s execution linking back to the parent. Important caveat: no consulted source states how a sub-workflow run counts toward a Cloud execution quota. If your design uses sub-workflows, verify billing behaviour against your own invoice before relying on it.

If you self-host, every one of those variables is yours to set directly — see our self-host n8n on a VPS with Docker guide for the hosting side. Self-hosting also changes the licensing picture: n8n is fair-code, not fully open source, as our fair-code licence explainer sets out. The Community Edition lives in the n8n GitHub repository (209,347 stars at fetch time — a point-in-time figure).

A worked example: the noisy inbox

This is an invented worked example, not a measurement. Suppose a support inbox produces 400 emails/day. At 400 × 30 = 12,000 trigger fires/month, a naive workflow that processes every email burns 12,000 executions — nearly five Starter quotas. Now suppose an allowlist passes only 40/day (the senders and labels that actually matter): 40 × 30 = 1,200 executions/month, inside Starter’s 2,500, with 10,800 refused runs each costing milliseconds instead of an LLM call. Your real numbers will differ; the shape is the point — the gate moves work from “every trigger fire” to “every fire that survives three cheap checks.”

Proving the gate works (without watching it run)

You can verify the gate’s behaviour from n8n’s execution list and settings alone, because the evidence is in what gets saved and refused. With EXECUTIONS_DATA_SAVE_ON_SUCCESS set to none and failed executions still saved, the execution list becomes a failure log — every entry is a run that actually needed attention. To see refusals during setup, temporarily save successful executions, confirm a few runs exit at the Filter or Remove Duplicates node without reaching the expensive branch, then flip saving back off. The pruning defaults (14 days / 10,000) bound your evidence window, so adjust a specific workflow’s save settings rather than relying on the global default. This is a documentation-derived procedure, not a claim that we watched it happen.

Failure modes and fixes

Failure mode	Symptom	Fix
Dedupe key on a mutable field	Duplicates slip through (edited subjects) or new items get suppressed (shared timestamps)	Dedupe on a stable unique ID — message ID, event ID — as the docs require for `Value Is New`
Dedupe history overflow	Duplicates re-appear after high volume	Remember History Size defaults to 10,000 items; if daily volume exceeds that, old IDs age out — plan a periodic Clear Deduplication History or a different key
Mixed AND/OR in one Filter node	Condition builder won’t express the allowlist logic	Chain two Filter nodes, or use an IF node where two branches are genuinely needed — the docs forbid mixing AND and OR in one rule set
Visual panel filter mistaken for real filtering	Items “disappear” in the panel but flow through on execution	Build an actual Filter node; the panel is “purely visual” and resets on reopen
Broken trigger crash loop	A failing trigger burns executions and alerts repeatedly	Enable `N8N_WORKFLOW_AUTODEACTIVATION_ENABLED` so 3 crashed executions unpublish the workflow
Sub-workflow billing surprise	Cloud invoice doesn’t match expected execution counts	No consulted source documents how sub-workflow runs count toward a Cloud quota — verify against your own usage before scaling that pattern

FAQ

Does a Filter node reduce my billed executions?

No. Every n8n execution is billed per workflow run, not per node, so a Filter node changes what happens inside a run, not how many runs occur. What it saves is the cost of expensive downstream nodes (API calls, LLM usage) inside that run — and it keeps refused items from generating alerts.

Should I use Filter or IF for the allowlist?

Use Filter for a pass-through gate; use IF when you genuinely need two branches handled differently. Both support AND and OR, but Filter cannot mix them in one rule set, and IF has only true/false outputs — more than two needs the Switch node.

What should I use as the dedupe value?

Use an input field or combination of fields with a unique ID — a message ID, event ID, or similar immutable identifier. Avoid timestamps (two distinct events can share one) and subject lines (people edit them); a mutable key either suppresses new items or lets duplicates through, silently in both cases.

How long does Remove Duplicates remember items?

With Value Is New, the History Size setting controls it, and n8n stores 10,000 items by default. If your item volume exceeds 10,000 between relevant periods, oldest IDs roll out of history and duplicates can reappear — size accordingly or clear history deliberately.

Does a refused run still count as an execution?

Yes. On n8n’s model an execution is a single run of the entire workflow regardless of steps or data volume, so a run that exits at the gate still consumes one execution. The gate’s savings come from cheaper runs, fewer downstream API costs, and a trigger-side prefilter that stops runs starting at all.

The Bottom Line

n8n’s whole-workflow billing makes the number of started runs the only real cost lever, and an admission gate — prefilter at the trigger, allowlist with a Filter node, dedupe on a stable unique ID with Remove Duplicates, silence when there’s nothing to do — is the documented way to pull that lever. At $20 ÷ 2,500 = $0.008 per execution on Starter, a noisy trigger you could have filtered at the source is the most expensive thing in your workflow.

Recommendation: build the gate in this order — prefilter, allowlist, dedupe, silence — and verify it from the execution list before trusting it with your quota.

How This Guide Was Built

This guide was assembled entirely from official n8n documentation and vendor pricing pages on 2026-11-02; it was not run hands-on — no workflow was built, executed, or measured for this post. Sources consulted: the n8n pricing page, Zapier pricing and Make pricing, plus the n8n docs for Remove Duplicates, Filter, IF, Wait, Execute Workflow, execution data pruning and workflow settings. What was not done: no workflows were executed, no timings or latencies measured, no inbox volumes observed, and no sub-workflow billing behaviour verified — the docs do not state how sub-workflow runs count toward a Cloud execution quota. All worked numbers are labelled arithmetic from stated inputs; the 400/40 inbox example is an invented illustration.

ToolBrain — tool reviews, LLM comparisons, and AI workflow guides

Cross-links automatically generated from NoCode Insider.