n8n is fast when you first install it. Two or three months in, you'll notice the editor getting sluggish, the execution list taking forever to load, and saving a workflow occasionally making you wait.
The instinctive reaction is that you're short on resources and should upgrade. Most of the time you aren't.
The 30-Second Overview
| Item | Details |
|---|---|
| Why it grows | The input and output of every node in every execution is saved |
| Which workflows are worst | High frequency × large data volume × many nodes |
| Symptoms | A sluggish editor, an execution list that takes ages to load |
| The single most effective fix | Don't save successful executions, or keep them briefly |
| Watch out for | Once it's deleted it's gone — don't treat it as a data source |
It Saves Every Single Execution
By default, n8n records the complete course of every execution — not just success or failure, but the input and output data of every node.
That design is extremely handy during development. When a workflow breaks, you click into that execution and see what each step received and emitted, and the problem is obvious.
The cost is this: a workflow that runs every five minutes runs 288 times a day, 8,640 times a month. If each run handles a few dozen KB, that's several hundred MB a month — and that's one workflow.
Which Workflows Grow Fastest
| Characteristic | Why |
|---|---|
| High trigger frequency | The record count multiplies directly |
| Large data volume per run | Pulling back a whole API response, reading an entire spreadsheet |
| Many nodes | Each node's input and output is stored separately |
| Attachments or images passing through | Binary data is especially space-hungry |
The third one is the easiest to underestimate. A workflow with fifteen nodes stores several times as much data per execution as a three-node workflow — and the data in the intermediate nodes is often duplicated.
What to Do About It
1. Set a retention period
The most direct approach: have n8n automatically delete executions older than a certain number of days.
How long depends on how far back you actually look. In practice, seven to fourteen days is enough for most people — if a workflow has been broken for two weeks without you noticing, what you need is failure notifications, not a longer history.
2. Keep only the failures
n8n lets you set separate retention policies for successes and failures. You will almost never go back and look at a successful execution; only the failures are worth anything.
Set successful executions to not be saved, or to a short retention, and the growth rate drops by an order of magnitude outright. This is the highest-return adjustment available.
3. Move less data than you need to
If a step in the middle of a workflow pulls back a big blob of data but everything after it only uses two fields, add a node right after that step to keep just the fields you need. That doesn't only save space — it makes execution faster too.
Think Before You Clean Up
One warning: once execution history is deleted, it's gone.
If you have workflows you rely on for reconciliation — checking "did this order actually go out yesterday?" for instance — write the critical information somewhere else before you clean up.
The more robust approach is not to depend on execution history as a data source at all. Important results should be written into a table deliberately, with execution history kept purely as a debugging tool. Then cleanup carries no anxiety whatsoever.
When You Can Just Ignore All This
Honestly: if your workflows run once or twice a day on small amounts of data, execution history won't reach a size that affects performance even in a year. You can leave this article for later.
The signals that you do need to act are very concrete — the editor is noticeably sluggish, the execution list takes several seconds, or storage is approaching your plan's limit. If any one of those three shows up, check your retention settings before rushing to upgrade your plan.
The plan is 1 vCPU / 2 GB storage (NT$5,988 billed yearly, avg. NT$499/mo). 2 GB is more than enough for the workflows themselves; what fills it up is almost always execution history.
Cleanup Treats the Symptom; Design Treats the Cause
A retention period keeps space under control, but the more fundamental fix is to stop each execution from generating that much data in the first place.
Three common forms of waste:
- Passing a whole API response all the way down — add a node in the middle that keeps only the fields you need, and every subsequent node's record shrinks
- Processing item by item in a loop — every iteration is another record; batch it if you can
- Forgetting to remove debugging nodes — those were added only to inspect intermediate results and should come out before you go live
Do those three things and the volume of history usually drops by more than half, while the workflow itself gets faster.
How to Estimate Your Growth Rate
You don't need precision — an order of magnitude is enough:
Executions per month = trigger frequency × runs per day × 20 working days
| Workflow | Executions per month | Growth rate |
|---|---|---|
| A once-daily report | About 20 | Negligible |
| An hourly sync | About 480 | Slow, but it accumulates |
| Every 5 minutes | About 5,760 | Set a retention period |
| A webhook-triggered form | Depends on actual traffic | Usually not much |
Then multiply by "data volume per run" and "number of nodes." A fifteen-node workflow that pulls back a whole API response each time can produce more than ten times the record size of a three-node workflow.
FAQ
Q: Does deleting execution history affect how workflows run?
No. The history is for humans; the workflow itself doesn't depend on it. The one exception is if you use it for reconciliation — in that case, write the critical information into a table deliberately rather than relying on the history.
Q: How long should I keep it?
Seven to fourteen days is enough for most people. The way to decide is to ask yourself "if a workflow broke, how long before I'd notice?" If the answer is two weeks, a retention period shorter than two weeks is pointless — but if the answer really is two weeks, what you actually need is failure notifications, not a longer history.
Q: Can I keep only the failures?
Yes, and it's the highest-return adjustment available. You'll almost never go back and look at a successful execution; only the failures are worth anything. Once configured, the growth rate usually drops by an order of magnitude.
Q: Is a slow editor always caused by this?
Not always, but it's the most common cause. Start by checking your storage usage — if it's clearly high while the workflows themselves are small, it's almost certainly the history.
Q: Any other options for high-volume workflows?
Yes. Add a node in the middle of the workflow that keeps only the fields you need, instead of letting a whole API response travel all the way to the end. That doesn't only save space — it makes execution faster too.
When to Treat It as a Warning Sign
Growing history is normal in itself, but sometimes it's a symptom of a different problem.
If one workflow's history is noticeably larger than the others', it's worth a look: is it being triggered repeatedly? Is an external service retrying the webhook? Is the schedule denser than it needs to be?
In that case, cleaning up the history just sweeps away the symptom; the trigger frequency is the thing to fix. Space growing faster than expected usually means the workflow is running more often than you think.
Sources and Further Reading
n8n's nodes and pricing change often, so here are the primary sources to check against:
- n8n official documentation
- n8n official pricing — cloud plans and quotas
- n8n source code and release history — the license terms here are authoritative
Further Reading
- n8n FAQ: Resource Limits, Webhook URLs, and Community Nodes
- n8n Webhooks and Third-Party Integration Guide
- n8n Plus NocoDB: Keeping Your Automation Data in Your Own Hands
- Is Self-Hosting n8n Cheaper? A Cost Table That Counts Your Time
- RoamerHost n8n Hosting Plans
Want Someone to Build It for You?
If you'd rather not build these workflows yourself, or the scope is big enough that you want help planning them, Roamer Tech (RoamerHost's parent company) takes on contract work for business process automation and AI agents:
