BuyKoreaNow – B2B SaaS Benchmarks & Software Intelligence

At 2:41 on a Tuesday morning, a Slack command goes quiet. No error in Slack. Just silence, then a red toast from the gateway: 504. Behind it, a Make scenario is 96 seconds into a chain that reads a ticket, asks GPT-4o for a structured plan, embeds the answer, searches a vector store, and posts the result back. The webhook answered at 40 seconds with one word. Accepted.

That word is the entire bug. Make gives a webhook response 40 seconds, and when the clock runs out it does not fail, it acknowledges: 200 Accepted, scenario still running toward its 40-minute ceiling, caller still waiting for JSON that will never come. I noticed the same sentence in three community threads before I found it in Make’s own help page, in a responding section that most build guides skip. I read that page, moved Make’s price slider stop by stop, and went through n8n’s environment reference line by line. Here is the sixty-second fix, the Docker settings that stop the crash, and the $2,244 that decides which stack you keep.

Free plan: 1,000 credits, two active scenarios, 15-minute minimum interval. The Early 200 pattern fits inside it.

What the 40-Second Gate Actually Counts

Forty seconds, and it covers the whole hop. Make’s help center is explicit in the responding section: “The timeout for sending a response is 40 seconds. If the response is not available within that period, Make returns a ‘200 Accepted’ status.” Not the LLM call. Not the module before the response. The entire distance from the incoming request to the module that answers it.

Two clocks sit behind that sentence and people confuse them constantly. The response clock is 40 seconds. The scenario clock is 40 minutes on every paid plan and 5 minutes on Free, and it keeps running long after your caller has given up. A chain that finishes at 96 seconds is not a slow failure. It is a success nobody hears about, followed by a client that reports a timeout while the bill keeps climbing.

“The timeout for sending a response is 40 seconds. If the response is not available within that period, Make returns a ‘200 Accepted’ status.”

— Make Help Center, Webhooks: responding to webhooks (help.make.com, read November 7, 2026)

One more rule hides in the same article and catches anyone who scheduled their webhook: a Webhook Response module only works when the scenario runs immediately on data arrival. Schedule the scenario and Make queues the request, then warns that the response cannot be processed. If you see “Response can’t be processed when scenario is not executed immediately on data arrival,” the schedule is the fault, not the module.

Four Signatures, One Root Cause

Every report I read in Make’s community this week fits one of four shapes. None of them says “40 seconds” out loud, which is why the diagnosis takes an evening.

Failure Signatures: What You See vs What Is Happening (Make, 2026)

The 200 Accepted line is the one that ruins weeks. A gateway that receives a success code writes a clean log entry, the support ticket says “integration returns empty,” and the actual question, whether the response module was reachable inside 40 seconds, never gets asked. An entire Slack app gets rebuilt around this, twice, because the error logs said everything worked.

The 504 belongs to your edge, not to Make. Something in front of the webhook, a Cloudflare rule, an API gateway, an application load balancer, gave up waiting before Make’s own 40 seconds elapsed. That ordering matters: fix the edge timeout and you will simply expose the 40-second gate underneath it.

The Early 200 Pattern, Module by Module

The fix is not faster models. It is moving the answer in front of the work. Six modules, one afternoon, and the caller gets a receipt in under a second while the chain finishes whenever it finishes.

1. Keep the trigger instant. A Custom Webhook set to run immediately on data arrival. The moment you schedule it, the response module becomes decorative.
2. Second module: Webhook Response. Status 200, body {"status":"queued","job_id":"<stable id>"}. Use something you can look up later: the trigger’s own id, an order id, a hash of the payload. This is the whole trick, and it takes ninety seconds to build.
3. Router, then the heavy lane. Everything expensive, the model call, the embedding, the vector search, sits after the router in a branch that no client is waiting on.
4. Data Store as the job ledger. One record per job_id with state queued, running, done or error, plus a result field. This is your dead-letter queue and your status endpoint in the same object.
5. Error route with zero-credit handlers. Make does not charge credits for the Rollback, Break, Resume, Commit and Ignore modules, and routers are free too, so a retry loop with a sleep and a Break costs nothing until real work runs. On the third failure write state error and the reason into the same Data Store record.
6. A second webhook for status. GET /status?job_id= reads the Data Store and answers with a Webhook Response module, inside 40 seconds by construction, because it does no work. The client polls that, or your Slack bot posts the result when the heavy lane finishes.

The receipt leaves in the same second the request arrives, because the only work in front of it is a status code and a job id. Nothing about the model got faster. The gate simply never sees the chain, which is why the pattern survives a 4-minute agent loop as calmly as a 40-second one.

Scenario order (Make, instant Custom Webhook):
1  Custom Webhook            -> runs immediately on data arrival
2  Webhook Response          -> 200, body {"status":"queued","job_id":STABLE_ID}
3  Router                    -> lane A: heavy chain, lane B: audit log
4  Data Store: Add/Update    -> key STABLE_ID
                               state=queued|running|done|error, result, attempts, error
5  LLM / embedding / vector  -> lane A only, no client waiting
6  Data Store: Update        -> state=done, result=JSON
   Error route               -> Break (retry, no credits) -> after 3x: state=error
7  Second webhook + response -> GET /status?job_id= reads the Data Store, answers in ms

Where the Early 200 Pattern Bites

Make’s help page carries a warning that most tutorials leave out, and it lands exactly on this pattern: if the Webhook Response module sits in the middle of a scenario and a later module fails, the scenario is not deactivated. No error email, no automatic stop, just credits burning on a branch that failed. The early return buys your latency with your alerts.

Three counters make it safe. A watchdog scenario that watches the Data Store for records stuck in running or sitting in error, and posts to Slack once per record. Idempotency, meaning the job_id is derived from the caller’s event and a duplicate request returns the existing record instead of starting a second chain. And the “Process data in order” scenario setting when the order of events matters, because Make runs instant webhooks in parallel by default and two retries of the same job can otherwise interleave.

What this pattern does not fix is cost. Each step after the response still spends credits, and a heavy chain that runs 1,100 modules a day spends them whether or not anyone is listening. Async turns a reliability problem into a budget problem, which is a better problem, but a problem.

n8n in Docker: No Wall Clock, a Different Wall

Self-hosted n8n has no 40-second response budget. The Webhook node asks how you want to respond, immediately, when the last node finishes, through a Respond to Webhook node, or as a stream, and EXECUTIONS_TIMEOUT defaults to -1, which means off, with a configurable maximum of 3,600 seconds per workflow. For a chain that genuinely needs 96 seconds, that difference is the whole argument.

“By default, n8n uses memory to store binary data.”

— n8n Documentation, Binary data environment variables (docs.n8n.io, read November 7, 2026)

The wall moves instead of disappearing. On a 2 GB droplet, n8n dies quietly when three things line up: binary data held in memory, execution history that nobody prunes, and a Node heap with no ceiling. The defaults are decent but not tuned for payload work. N8N_DEFAULT_BINARY_DATA_MODE keeps binary data in memory unless you set it to filesystem. The webhook payload ceiling is 16 MB per request, and a PDF that size is 16 MB of heap on every hop until the execution ends.

The four settings below address those three causes, and each one is an environment variable in n8n’s own reference. None of them costs anything.

# docker-compose.yml, n8n service
environment:
  - N8N_DEFAULT_BINARY_DATA_MODE=filesystem
  - EXECUTIONS_DATA_PRUNE=true
  - EXECUTIONS_DATA_MAX_AGE=336
  - EXECUTIONS_DATA_PRUNE_MAX_COUNT=10000
  - NODE_OPTIONS=--max-old-space-size=4096
  - N8N_PAYLOAD_SIZE_MAX=16
  - DB_TYPE=postgresdb
  - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
  - GENERIC_TIMEZONE=Asia/Seoul
# reverse proxy (nginx): proxy_read_timeout 300s;  # default is 60s

• Binary mode filesystem moves attachments out of the heap. This is the single biggest change for document workflows, and it is one line.
• Pruning at 336 hours and 10,000 records keeps the database from growing into the disk. Both are environment variables, both default in the safe direction, and both are worth stating out loud in your compose file so the next person does not turn them off.
• A 4 GB heap on a 2 GB box sounds wrong and is not: the flag caps V8, it does not reserve memory. Without it Node’s default ceiling on a small instance is low enough that a large JSON parse ends the process.
• Proxy read timeout. nginx ships with a 60-second default. If your webhook responds when the last node finishes, that default kills the connection before a slow chain answers, and you will blame n8n for a proxy setting.
• Postgres and a backup of the encryption key. SQLite is fine until concurrency is not, and the encryption key is the one file whose loss makes every stored credential worthless.

What surprised me is how much of n8n’s reputation for fragility traces back to defaults on a small instance rather than to the code. Binary data in memory, execution history nobody prunes, and a heap ceiling set for a laptop: that combination describes most of the crash reports I read this week. Tune those three and the container is as boring as the $12 price suggests it should be.

The Bill at 100,000 Module Runs, Priced at a Stop You Can Buy

Here is where most comparisons quietly go wrong, including the draft of this one. Make’s credit slider does not offer 100,000. It steps 10,000, 20,000, 40,000, 80,000, 150,000, 300,000. An agency running 100,000 module runs a month buys the 150,000-credit Pro tier, because the 80,000 tier cannot hold the volume. Any article quoting a 100,000-credit price is quoting a plan Make will not sell you.

Prices below are the US list on make.com/pricing, read on November 7, 2026, both billing cycles. Annual billing on Pro prepays the year’s credits into one pool, which is worth knowing if your workload is seasonal.

The Real Bill: 100,000 Module Runs a Month (US Price List, Read November 7, 2026)

💡 The Hard Dollar Math: $2,388 – $144 = $2,244 a year, a 94.0% cut, measured on the tier that actually holds 100,000 module runs. Monthly billing widens it to $3,108, and the 300,000 spike stop widens it to $4,044.

So the annual number is $2,388 for the Make seat against $144 for a DigitalOcean 2 GB droplet running n8n Community, whose licence is free and whose feature set is close to complete. Call it $2,244 a year, a 94.0% cut, with $3,108 if you pay Make monthly instead. At the 300,000-credit stop a busy quarter costs $4,188 on annual billing and $5,688 on monthly, against the same $144.

What the arithmetic leaves out is what the cheap side actually costs. Two to four hours a month of updates, backups, certificate renewals and the occasional 2 a.m. container, priced at whatever your hour is worth. At $150 an hour, three hours a month is $5,400 a year, which is more than twice the $2,244 you saved. That breakeven is the honest shape of this decision: n8n is cheaper in dollars and more expensive in attention, and only your calendar says which one binds.

Where n8n Stops Being Free

The Community edition is free under n8n’s licence, and it is not crippled. Registered Community adds folders, debug in editor and custom execution data for an email address. The paid self-hosted tiers exist for a different reason: SSO and LDAP, multiple environments, Git-based version control, queue mode and project roles. The Business plan is 667 euros a month. The moment a client asks for single sign-on or a staging environment, the $144-a-year story ends and the comparison needs redoing.

n8n Cloud is a third option and a different animal. Starter is 20 euros a month billed annually for 2,500 executions with a 5-minute execution cap; Pro is 50 euros for 10,000 executions with a 40-minute cap. Executions count whole workflow runs, not steps, which is the one pricing idea here worth stealing: a 30-step chain billed per run is cheaper than one billed per module once the chain gets long. If your 100,000 number is module runs rather than workflow runs, n8n’s unit is the friendlier one by a wide margin.

The Decisive Reason: Why You Must Choose Make Today

When you strip away the marketing hype, here is the decisive unfair advantage that puts Make ahead of every legacy alternative:

• 1. The 40-second gate is a design constraint, not a defect: It cannot be raised, so the only stable answer is to answer early. That single pattern, a Webhook Response in slot two with a job id, removes the timeout without a server, a certificate or an update window. It is the cheapest reliability upgrade in this entire comparison.
• 2. The 150,000 tier is still one invoice: At $199 a month billed annually, the whole chain runs on a platform someone else keeps up at night. No container, no proxy, no Postgres, no 2 a.m. restart, and the 40-minute execution ceiling is long enough for any chain that returns early.
• 3. Error handlers and routers cost nothing: Make does not charge credits for Rollback, Break, Resume, Commit, Ignore or the Router module, so a retry loop with a sleep built on those costs $0 until real work runs. A dead-letter path is free to design properly.
• 4. 3,500+ apps with one-click OAuth: The tokens your chain needs, Slack, Notion, Airtable, Gmail, HubSpot, are a button instead of an HTTP node and a credential dance. For an agency building for clients, that is billable hours not spent.
• 5. The honest limit: credits scale with steps: Every module run is a credit, so a 30-step chain at 3,000 runs a month is 90,000 credits and a 150,000 tier. Once the workload passes 300,000 credits, the annual invoice is $4,188 and the self-hosted arithmetic stops being a rounding error.

The Honest Catch (What Frustrated Me and How to Fix It)

The Real Limitation: Make will not raise the 40 seconds, and a mid-scenario response means later failures no longer deactivate the scenario: credits keep burning with no error email. The Free plan stops at 1,000 credits, two scenarios and a 15-minute interval, and the 100,000-credit plan this post would have liked to price does not exist, so the real purchase is the 150,000 tier at $199 a month annual or $271 monthly. On the n8n side, the free licence still bills you in attention: binary data starts in memory, execution history grows, Node’s heap is small by default on the cheap droplets, and nginx’s 60-second read timeout will cut a synchronous response before n8n does.

My Practical Workaround: Put the Webhook Response in slot two, keep a Data Store ledger keyed by a stable job id, and run a watchdog scenario that pages you when a record sits in running or lands in error, which is the one alert the mid-scenario response takes away. Derive the job id from the caller’s event so a retry cannot start a second chain. On n8n, four lines in compose, filesystem binary mode, pruning at 336 hours and 10,000 records, a 4 GB heap flag, and a 300-second proxy read timeout, address those three causes directly. Price the tier you will buy at checkout, not the tier in a comparison table.

Keep Reading

The plan-by-plan canvas comparison, without the webhook material, is Make vs n8n in 2026. The same error-fix intent applied to DNS lives in the Cloudflare 525 handshake fix, the database version of it is the Supabase RLS recursion fix, the infrastructure bill for a working trip is Airalo vs Saily, and the video layer that feeds these chains is HeyGen vs Colossyan.

Primary sources, if you would rather read them than trust me: Make’s Webhooks help article, the Make pricing page with its credit slider, n8n’s Webhook node documentation, n8n’s environment variable reference, and DigitalOcean’s droplet pricing.

Frequently Asked Questions (AEO Direct Answers)

Q: Why does my Make webhook return 200 with the body Accepted instead of my data?
A: Because the scenario had no Webhook Response module reachable inside the 40-second response window, so Make sent its default acknowledgement. Make’s help center states it plainly: the timeout for sending a response is 40 seconds, and if the response is not available in that period Make returns a 200 Accepted status. Your caller receives a success code and no payload, which is why the failure looks like an empty result rather than an error. Add a Webhook Response module immediately after the trigger and send the real payload later through a job id your client polls.

Q: Can the 40-second limit be raised on Make?
A: Not by configuration. The 40 seconds is the platform’s response budget for a webhook call, separate from the 40-minute maximum execution time a paid scenario gets (5 minutes on Free). You can shorten the work in front of the response module, or you can move the work behind it. Returning an acknowledgement first and processing asynchronously is the only pattern that survives a chain whose honest runtime is 90 seconds or more.

Q: Does n8n self-hosted have a webhook timeout at all?
A: The self-hosted instance has no built-in 40-second response gate. The Webhook node’s Respond setting offers Immediately, When Last Node Finishes, Respond to Webhook node and Streaming, and EXECUTIONS_TIMEOUT defaults to -1, which is disabled, with a configurable maximum of 3,600 seconds per workflow. What still bites you is everything in front of the container: nginx’s default 60-second proxy_read_timeout, a load balancer idle timeout, and the caller’s own patience. n8n Cloud is different: Starter caps an execution at 5 minutes and Pro at 40 minutes.

Q: What actually causes the n8n Docker container to die with an out-of-memory kill?
A: Binary data and execution history. N8N_DEFAULT_BINARY_DATA_MODE defaults to keeping binary data in memory, so a workflow handling a 12 MB PDF holds it in the Node heap, and a 16 MB webhook payload is the documented ceiling per request. Execution records pile up too. Setting N8N_DEFAULT_BINARY_DATA_MODE=filesystem, keeping EXECUTIONS_DATA_PRUNE=true with EXECUTIONS_DATA_MAX_AGE=336 and EXECUTIONS_DATA_PRUNE_MAX_COUNT=10000, and raising the V8 heap ceiling through the NODE_OPTIONS flag on a 2 GB or larger instance covers the three usual causes.

Q: Which is cheaper at 100,000 module runs a month in 2026?
A: n8n Community on a $12-a-month 2 GB droplet costs $144 a year plus your maintenance time. On Make, 100,000 module runs does not fit a 100,000-credit plan because that stop does not exist: the slider steps from 80,000 to 150,000, so the purchase is Pro at 150,000 credits, which is $199 a month billed annually ($2,388 a year) or $271 monthly ($3,252 a year). The annual difference is $2,244, a 94.0% cut, before you count the two to four hours a month of updates, backups and monitoring that the cheaper route asks of you.