Home / Blog / Business Applications and Automation / n8n Webhooks, Queues, and Execution Retention Explained
Three settings decide whether a busy n8n instance stays responsive or slowly grinds to a halt: how webhooks are received, whether executions run in queue mode, and how long execution history is kept. They are connected. A webhook that arrives during a traffic spike has to be accepted, queued, executed, and recorded — and if any part of that chain is misconfigured, you get lost webhooks, stuck jobs, or a database that grows until the disk fills.
This guide explains each piece in plain terms, the defaults that catch people out, and the settings worth changing before your instance gets busy.
A webhook is an HTTP request sent to n8n by another service — a form submission, a payment notification, a new order. The webhook node in your workflow defines the URL and the HTTP method. When a request arrives, n8n starts an execution of that workflow.
There are two ways n8n can handle that moment:
Which behaviour you get depends on the webhook node’s response settings. Before you design a workflow around a webhook, check what the sending service expects: a fast acknowledgement, or a meaningful response body. A payment provider that retries on timeout will happily send the same event three times if your workflow takes too long to answer — so design for duplicates, for example by checking whether the event has already been processed before acting on it.
The most common webhook complaint is that everything works locally and fails on the server. The usual cause is the public URL. Behind a reverse proxy, n8n may generate webhook URLs based on its internal address instead of your public domain. Set the public webhook URL explicitly in your environment (WEBHOOK_URL, or N8N_WEBHOOK_URL in older versions) to your full public address, for example https://n8n.yourdomain.com/, and make sure your proxy passes the original host and protocol headers through. Also confirm the webhook URL is reachable from the internet — a firewall rule or a missing DNS record will silently drop every incoming event.
By default, n8n runs in regular mode: a single process handles the editor, receives webhooks, runs schedules, and executes workflows. That is fine for light use. It becomes a problem under load, because one long or heavy execution can block others, and if the process crashes or runs out of memory, every active workflow dies with it.
Queue mode separates the work. The main process handles the editor, webhook reception, and scheduling, while separate worker processes execute the workflows. Jobs pass between them through Redis. If a worker crashes, the queued jobs wait and are picked up when a worker returns, rather than being lost with the crashed process.
To enable queue mode, the key settings are:
EXECUTIONS_MODE=queue
QUEUE_BULL_REDIS_HOST=redis
QUEUE_BULL_REDIS_PORT=6379
You then start worker processes alongside the main instance:
n8n start # main process: editor, webhooks, scheduling
n8n worker --concurrency=10 # worker: executes workflows
A few rules that matter:
Queue mode is not magic: it adds Redis as a moving part. For a handful of low-volume workflows, regular mode with a sensible retention policy is simpler and perfectly adequate.
Every time a workflow runs, n8n can save the execution: its status, the data that passed through each node, and any error. That history is invaluable for debugging — you can open a failed run and see exactly which node received what. It is also the fastest way to fill a database.
By default, n8n keeps a lot. A workflow that runs every minute produces over 40,000 executions a month. A busy sync workflow can produce thousands a day. The default count cap (10,000 executions) sounds generous until a single chatty workflow hits it in five days, and then older history starts being deleted regardless of age.
These environment variables control what is saved and for how long:
EXECUTIONS_DATA_SAVE_ON_SUCCESS=all
EXECUTIONS_DATA_SAVE_ON_ERROR=all
EXECUTIONS_DATA_SAVE_ON_PROGRESS=false
EXECUTIONS_DATA_SAVE_MANUAL_EXECUTIONS=false
EXECUTIONS_DATA_PRUNE=true
EXECUTIONS_DATA_MAX_AGE=168
EXECUTIONS_DATA_PRUNE_MAX_COUNT=50000
What each one does:
EXECUTIONS_DATA_SAVE_ON_SUCCESS — whether to save data for successful runs. Setting it to none saves the most space: the run is recorded as successful, but the data that passed through the nodes is not stored. The trade-off is that you cannot inspect a successful run afterwards, which matters when a customer asks why an invoice went out twice.EXECUTIONS_DATA_SAVE_ON_ERROR — whether to save data for failed runs. Keep this at all in almost every setup; failed runs are the ones you need to debug.EXECUTIONS_DATA_SAVE_ON_PROGRESS — whether to write to the database after every node, which allows resuming a failed run from the node where it stopped. Leave it off unless you rely on that resume behaviour; on a busy workflow the write traffic is significant.EXECUTIONS_DATA_SAVE_MANUAL_EXECUTIONS — whether to save runs you trigger by hand from the editor. Turning it off keeps test runs out of your history.EXECUTIONS_DATA_PRUNE — enables automatic deletion of old executions. Without this, history grows without limit.EXECUTIONS_DATA_MAX_AGE — how long to keep executions, in hours. 168 is one week; 336 is two weeks.EXECUTIONS_DATA_PRUNE_MAX_COUNT — the maximum number of executions to keep. Whichever limit bites first — age or count — is what deletes your history, so set both deliberately for your volume rather than assuming the age limit is the one in control.A balanced starting point for a production instance is: save everything on error, save success data for a short window (72 hours to one week), prune automatically, and set the count cap to fit your database size. If you need longer audit history, export execution data to external storage rather than keeping it all in the live database.
Execution history is operational data, not a backup: pruning deletes it by design. Back up workflows, credentials, the key, and the database separately — see how to back up and restore n8n workflows and credentials.
Two more settings prevent a busy instance from collapsing:
N8N_CONCURRENCY_PRODUCTION_LIMIT) caps how many production executions run at once. Without a cap, a burst of webhooks can exhaust memory. Start at the worker default of around 10 parallel executions per worker and adjust based on whether your workflows are CPU-heavy (lower) or mostly waiting on APIs (higher).EXECUTIONS_TIMEOUT) caps how long a single execution may run. Without one, a stuck workflow can consume memory indefinitely. Set a timeout that is generous for your slowest legitimate workflow and short enough to kill a genuinely stuck one.Queue mode means running Redis and PostgreSQL alongside n8n, plus one or more worker processes. That is a small multi-service deployment, and it needs a server with enough memory, persistent volumes, and the freedom to run Docker containers and set environment variables. A VPS hosting plan is the usual fit: you control the services, the versions, and the retention settings, rather than inheriting someone else’s defaults. [TO BE CONFIRMED: whether Offshore Hosting VPS plans include Redis/PostgreSQL support or managed n8n — confirm before publishing any such claim.]
Email on your own domain looks professional and stays yours when you change providers. This guide explains what business email hosting involves, how it differs from free webmail, and the DNS and deliverability pieces that make it work.
Latency figures are widely quoted and widely misunderstood. This guide explains what ping measures, which hop actually matters, and the limits of what a VPS can do.
A complete n8n backup covers workflows, credentials, the encryption key, and the database. This guide shows each method, what each one misses, and how to test a restore.