n8n keeps restarting or runs out of memory
It dies mid-run, or the editor crawls, or a small machine kills it. Usually one workflow and one setting, not a machine that is too small.
What you are seeing
n8n restarts on its own, often at the same point in the same workflow.
The logs mention a heap that ran out of memory, or the process is simply killed with no message at all, which is the machine doing it rather than n8n.
Everything is slow after a few weeks of running fine.
Why it happens
Everything a step produces is held in memory at once
n8n passes the full result of one step into the next. Fetch five thousand rows and all five thousand are in memory together, then again in the next step, and again in the one after that.
A workflow that is fine with ten items and fatal with ten thousand is the single most common version of this, and the fix is in the workflow rather than in the machine.
Files are the fastest way to fill it
Downloads, attachments and generated documents are held in memory by default. A handful of large files inside one run will do what thousands of rows of text will not.
The slow version: execution history that nobody prunes
Every run is saved, including the successful ones and everything they passed around. On the default single file database this grows without limit, the file gets large, and everything touching it gets slower. This is the one that shows up as "it was fine for a month".
How to fix it
Work in batches, which fixes it properly
Ask for less at a time. Page the source, or put the items through a batching step and let the workflow loop. A batch of fifty in a loop uses a fiftieth of the memory of five thousand at once, and it takes about the same wall clock time.
Drop fields you do not need as early as possible. Carrying the whole record through eight steps when you needed two fields is a memory bill you pay eight times.
Stop holding files in memory
Switch binary handling to disk. It needs somewhere permanent to write, so pair it with real storage or it becomes the workflows-disappeared problem instead.
environment:
- N8N_DEFAULT_BINARY_DATA_MODE=filesystemPrune the execution history
Turn pruning on, keep a fortnight, and stop saving successful runs of anything that fires every minute. You almost never read those, and they are most of the volume.
environment:
- EXECUTIONS_DATA_PRUNE=true
- EXECUTIONS_DATA_MAX_AGE=336 # hours, so fourteen days
- EXECUTIONS_DATA_PRUNE_MAX_COUNT=10000Only then, give it more room
Raising the heap limit above what the machine actually has does not help. It converts a clear error message into a silent kill, which is worse. Raise it only if the machine has the memory spare, and treat it as a stopgap rather than a fix.
environment:
- NODE_OPTIONS=--max-old-space-size=1536 # on a machine with at least 2 GBStopping it happening again
Size it for the spike, not the average
n8n idles cheaply and spikes hard. What kills it is one run that is ten times the usual size, so the number that matters is the worst run, not the typical one.
A very small machine can genuinely run n8n. It cannot run n8n and a browser and three other things, and a machine that sleeps cannot run anything on a schedule at all.