Webhook Dropping

Questions
1

Hi I’m creating a workflow with LINE webhook as a trigger, using starter plan. However, when multiple images/message sent simultaneouly (assuming 6 webhooks), 3 or half get dropped, no queuing or waiting. LINE webhook show no errors message. It likes the three never happened.
I’m using n8n cloud though

Describe the problem/error/question

What is the error message (if any)?

Please share your workflow

(Select the nodes on your canvas and use the keyboard shortcuts CMD+C/CTRL+C and CMD+V/CTRL+V to copy and paste the workflow.)

Share the output returned by the last node

Information on your n8n setup

  • n8n version:
  • Database (default: SQLite):
  • n8n EXECUTIONS_PROCESS setting (default: own, main):
  • Running n8n via (Docker, npm, n8n cloud, desktop app):
  • Operating system:
2

Welcome @Natchanan_Kiatrungwi!

This is a concurrency limit issue on the n8n Cloud Starter plan. The Starter plan caps how many workflow executions can run in parallel - when multiple LINE webhook events arrive simultaneously, the ones exceeding the concurrency limit get silently dropped (no error, no queue, no trace in the execution list).

Each LINE webhook hit triggers a separate n8n execution, so 6 simultaneous events will likely hit the cap and have some silently discarded. Two ways to handle this: upgrade to a plan with higher concurrency, or restructure so a single webhook receives all events and processes them sequentially inside one execution using the Loop Over Items node. You can also check your plan’s concurrency limit under Settings > Executions in n8n Cloud.

3

Hi @Natchanan_Kiatrungwi

In addition to what @nguyenthieutoan has mentioned, you can also do this:

  1. Open your LINE Webhook node.
  2. Look for the setting HTTP Response Code.
  3. Change the Response Mode from When Last Node Finishes to Immediately.

Why this works: By responding “Immediately,” n8n sends a 200 OK back to LINE the millisecond the request is received. This closes the connection instantly and frees up the “slot” for the next incoming webhook. The workflow then continues to run in the background. This prevents the server from choking on open connections.

4

The reply above has it: this is the concurrency cap on n8n Cloud Starter. When six LINE webhooks land at once, the executions over your plan’s parallel limit get dropped, and the nasty part is exactly what you saw, no error, no queue, no trace, the three just never happened. That is the worst kind of failure because nothing flags it.

Two ways to handle it. The quick one is to make the webhook do as little as possible and hand off fast: have the trigger workflow immediately push the incoming payload into a queue or a Data Table (or a second workflow via a queue), so the webhook itself returns in milliseconds and is far less likely to be the one dropped under burst. The execution that does the real work then drains the queue at its own pace. The other is the plan-level fix: higher tiers raise the concurrency limit, so if bursts of simultaneous messages are normal for this client, the Starter cap will keep biting.

Either way, add a counter you can see: log every inbound webhook the moment it arrives (before any processing) so you can compare received-vs-processed and actually know when LINE sent more than n8n handled. Right now the dropped ones are invisible, and invisible is what makes this dangerous on a client workflow. Are the bursts predictable (a campaign) or random? That decides queue vs plan upgrade.