n8n vs Make at 20,000 runs, and when a step fails

A lead fills in the form on your website. A webhook catches the message, a filter drops anything without a phone number, and HubSpot creates or updates the contact. Twilio then texts the lead to say the message arrived, and Slack tells whoever is on shift. This n8n vs Make comparison prices that one five-step workflow on both tools, at 1,000 runs a month and at 20,000.

At 1,000 runs, Make's Core plan costs $9 a month and n8n's Starter plan costs €20, both billed yearly. At 20,000 runs, Make's Core plan costs $55. The plans n8n lists for its cloud stop at 10,000 executions a month, so on n8n the same volume means a talk with sales or a server of your own. After the prices, this page follows the workflow into a failure at step three, where the two tools differ most. None of the seven pages ranking for this search follows a failed step that far.

The prices were read from each vendor's pricing page on 15 September 2026. The failure behaviour comes from each tool's own documentation, not from running the workflow.

The short version Hosted, Make costs less than n8n at 1,000 runs, and it is the only one of the two with a listed price at 20,000. n8n costs less once it runs on a server of your own, and from then on keeping that server healthy and noticing a failed run are your job.

How each tool counts one run#

Make bills in credits. Its pricing page counts one credit for each module action, and a filter sits between modules rather than being one. On my count, this workflow uses 4 credits a run: the webhook plus the three app steps.

The n8n pricing page bills by executions instead, and it defines one as a single run of the whole workflow, however many steps it has. Every lead costs one execution, whether the workflow has five steps or twenty.

Neither count covers the rest of the bill. Twilio charges for each text and HubSpot has plans of its own, whichever tool runs the steps, so both are left out of every price here.

At 1,000 runs a month#

A thousand runs is 4,000 credits, which lands on Make's first paid step of 10,000. Core costs $9 a month there billed yearly, or $10.59 billed monthly, and keeps scenario logs for 30 days. The free plan's 1,000 credits would cover 250 runs, so it is out.

On n8n, the Starter plan covers 2,500 executions a month for €20 billed yearly, or €24 billed monthly. It runs five executions at a time and keeps each execution's record for 7 days.

Self-hosting n8n moves the cost from executions to a server. The Community Edition carries no licence fee, and its Sustainable Use License allows it for your own internal business purposes. The n8n docs give no minimum server size, so treat $6 to $12 a month as a starting point, the price of DigitalOcean's 1 GiB and 2 GiB Droplets. Weekly backups add 20 percent.

At this volume the hosted bills are $9 and €20 a month, which is too small a gap to choose on. If this is the first workflow the business is automating, what to automate first matters more than either plan.

At 20,000 runs a month#

Twenty thousand runs is 80,000 credits, which is one of Make's steps. Core costs $55 a month there billed yearly, or $64.71 monthly. The Pro and Teams plans cost $91 and $172.90 at the same step, for the same credits, so what they add is features rather than room.

On n8n's cloud, 20,000 executions is twice what Pro includes. Pro costs €50 a month billed yearly, or €60 monthly, for 10,000, and the next plan the page lists is Business, at €667 a month billed yearly for 40,000 executions. Business is marked self-hosted, and the hosted route above Pro is Enterprise, priced by sales. The page's FAQ describes running over the allowance only for Business and Enterprise, where workflows keep running and each extra block of 300,000 executions costs €4,000, invoiced 45 days later.

Self-hosted, the Community Edition has no execution meter, so 20,000 runs cost the same $6 to $12 a month for the server. That is about 667 runs a day, or one every two minutes on average. What grows is the time someone spends keeping the server patched and backed up.

When step three fails#

HubSpot can fail this workflow in two ways. It can be unavailable or throttling requests, or it can refuse what it is sent, because a required field is malformed or the saved login has expired. The two tools treat those cases differently, and the defaults are what a new workflow runs with.

On Make, an outage or a rate limit pauses the scenario for 20 minutes, according to Make's error reference. A scenario that starts with a webhook then reruns the work or retries it with growing gaps. A refusal ends the run with an error instead, so the text and the Slack alert never go out.

Here is the part to know before launch. Make's scenario settings include a count of errors allowed before a scenario is switched off, but a scenario that starts with an instant trigger ignores it. A webhook is an instant trigger, so the first refusal switches the whole workflow off.

Leads keep arriving while it is off. Make's webhook documentation says requests it cannot process straight away wait in a queue. The queue holds 667 items for every 10,000 credits on the plan, up to 10,000, and Make rejects anything over that. On Core at 10,000 credits that is 667 leads, about 20 days at 1,000 runs a month. At 80,000 credits it is 5,336 leads, about eight days at 20,000 runs a month.

Someone does hear about it. By default Make sends an email when an error stops a scenario or switches it off, according to its email preferences page. Two settings help the next time. The first is incomplete executions, which are off by default and keep a failed run with its data so it can be retried. The second is an error handler on the HubSpot module, which can retry the step or skip it at no credit cost.

On n8n, the execution stops at the HubSpot node and is marked failed, so here too the text and the Slack alert never go out. Nothing tries again unless the node's Retry On Fail setting was switched on, and that setting is made for short blips. The cap is five tries, at most five seconds apart, a limit n8n's maintainers closed as working as expected. That covers about 20 seconds, not an afternoon of HubSpot trouble.

The way n8n's docs describe hearing about a failure is an error workflow, a second workflow that starts when an execution fails and can post to Slack or send an email. It has to be chosen in each workflow's settings. Once HubSpot is back, the failed run can be retried from the executions list, with the workflow as it was or as it is now. Starter keeps executions for 7 days and Pro for 30, so on Starter a failure nobody checks for a week disappears. With Autoreplay switched on, Zapier keeps retrying the same failure for more than ten hours, as n8n vs Zapier shows.

Saving the lead before any outside call#

The third lane in the figure is the same workflow as code you own, and what changes is the order of the steps. The lead is written to your own database before anything calls HubSpot, so a HubSpot failure delays the handover instead of stopping it. A scheduled job retries the failed call, and after a set number of tries a person gets a message. The contact form on this site starts the same way, saving every message to its own database before anything else runs.

Hosting a workflow like this fits Cloudflare's Workers free plan, which allows 100,000 requests a day against the 667 a day of 20,000 runs a month. At 1,000 runs a month, Make's Core plan is $108 a year, and that bill alone is no reason to write code. Code earns its place when the workflow carries most of the business's leads and rarely changes, because every change goes through a developer.

Before the first real lead#

Whichever tool runs it, set up the failure path before the workflow goes live. On Make, that means incomplete executions and an error handler on the HubSpot step. On n8n, it means an error workflow, and a plan that keeps executions long enough for someone to look. Then run the workflow once by hand with a lead whose email address is malformed, and watch where the error lands.