n8n execution timeout: why a long URL list stops halfway

Your workflow reads 500 URLs, fetches a few dozen and then stops. Sometimes the editor says the node ran out of memory. Sometimes it says "Connection Lost". Sometimes the run just ends after a node finishes. These are different limits, and n8n documents them in different places. This post sorts them out, then builds the split that keeps every execution far from all of them.

Step 1: Read the symptom

Open the failed execution in Executions. Compare what you see with this table.

What you see: one of the four rows matches. On n8n Cloud and in Docker the instance restarts by itself after a memory crash. With an npm install you may have to restart it by hand.

Step 2: Know your memory budget

A long URL list can hit memory before any timeout: if one execution fetches 300 pages, its data can hold 300 page bodies at once.

n8n Cloud publishes the RAM per plan:

n8n itself uses around 180MiB of that on average. On Starter that leaves roughly 460MiB for your data, for other workflows that run at the same time, and for the editor.

The memory guide names more things that make it worse. Manual executions copy data for the frontend, so do not test a 500-URL run by hand in the editor. The Code node is memory-heavy, so do not reshape page bodies there if a built-in node can do it. The guide's own example of the fix: process 200 rows per execution instead of 10,000.

What you see: a rough idea of how much fits. You do not need an exact number. The split in Step 4 keeps you far below it.

Step 3: Set the timeout on purpose

Open the workflow, then Settings. Turn on Timeout Workflow. A Timeout After field appears with hours, minutes and seconds.

On n8n Cloud, each plan has a maximum timeout that n8n enforces. The docs do not publish the figure for each plan. Do not plan around a number you read in a forum.

Self-hosted, two environment variables apply, both in seconds:

# The default is -1: no timeout. One hour for every workflow:
export EXECUTIONS_TIMEOUT=3600
# The highest timeout a single workflow may set in its own settings:
export EXECUTIONS_TIMEOUT_MAX=7200

The timeout is soft. In the main process, n8n lets the running node finish and then stops the workflow. When executions run in their own process, n8n kills the process if it is still running after one fifth of the timeout. That is why a timeout looks like a clean stop: the HTTP Request node finished its items, and the next node never ran.

What you see: a known ceiling for every run, instead of a stop that looks random.

Step 4: Split the list into small executions

This is n8n's documented fix for memory, and short executions also stay far from any timeout. The parent holds URLs. The child holds pages, but only one chunk at a time.

Parent workflow:

1. Schedule Trigger.
2. Google Sheets, read the rows that still need a fetch.
3. Loop Over Items, set "Batch Size" to 20.
4. Execute Sub-workflow. Set "Source" to "Database" and pick the child "From list". Set "Mode" to "Run once with all items". Leave "Wait for Sub-Workflow Completion" on.
5. Connect the sub-workflow output back to Loop Over Items.

Child workflow:

1. Execute Sub-workflow Trigger (on the canvas: "When executed by another node"). Set "Input data mode" to "Accept all data".
2. HTTP Request, one URL per item, paced as in Batching or Loop Over Items.
3. IF on {{ $json.statuses[0].status }} equals success.
4. Google Sheets, "Append or Update Row" on both branches, matched on url. Write status, fetched_at and the error tag.
5. A last node that outputs one small item, for example { "done": 20 }.

The last step matters. n8n's memory guide says each sub-workflow should return only a small result set to its parent, so memory is freed after each batch. Return a count, not the pages.

What you see: the parent runs a series of short child executions, one per chunk of 20 URLs.

The n8n web scraping guide has the full HTTP Request node table and the error routing per tag.

Step 5: Make a cut-off run resumable

Small executions limit the damage. Status rows make the run resumable.

Because the child writes a row per URL as it goes, a run that stops at chunk 7 has already written chunks 1 to 6. On the next run, the parent reads only the rows with an empty status, a retryable error, or a fetched_at older than your refresh window. Pages that already succeeded are not fetched again.

n8n also has Save execution progress in the workflow settings. With Save selected, a workflow can resume from where it stopped after an error, at some cost in latency. For a URL list, the sheet is the simpler record: you can see it, filter it and fix it by hand.

The same HTTP step on Cloud and self-hosted

None of this changes the fetch itself. If you use AgentScraper API as the HTTP step, one POST takes 1 to 10 URLs, and the rate limit counts URLs, not requests. Each URL comes back with its own status and fetch time in statuses[].fetchedAt, which is what the child writes to the sheet. Failed fetches cost 0 credits. To keep items small, cap the returned Markdown with text.maxCharacters. The node settings are in the no-code recipes.

What this means for your workflow

• Read the symptom first: a memory message, an instance restart, a heap error, or a stop right after a node.
• Cloud Trial, Starter and Pro-1 have 640MiB, and n8n uses about 180MiB of it.
• n8n does not publish the Cloud timeout per plan. Do not build around a forum figure.
• Self-hosted: EXECUTIONS_TIMEOUT and EXECUTIONS_TIMEOUT_MAX, in seconds. The default is no limit.
• The parent holds URLs. The child holds one chunk of pages and returns a count.
• One status row per URL, written by the child, lets the next run pick up where this one stopped.