Describe the problem/error/question
I am self hosting n8n on Hostinger. I’ve been slowly migrating over from make.com and generally loving it but one thing just bites me over and over again.
Basically if I have a sub workflow that runs over a minute, when it returns back to the calling parent workflow all existing context data for nodes run prior to the sub workflow are null.
With LLM calls in the sub workflow you can almost guarantee that it’s going to hit the issue. This is really my only gripe with n8n and I’m hoping I’ve just missed something.
I don’t know if I have a setting wrong or if I am missing something that would help but it’s driving me insane with the workaround I use (pass all values i want to keep using into the sub workflow and returning them at the end).
I’ve read through similar posts and info online but I haven’t really found any workaround other than the one I mentioned above.
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:
@Andrew_Parsons that exact 60s pattern points at ur reverse proxy timing out — nginx default is around 60s for proxy_read_timeout, so when ur sub-workflow exceeds it, the proxy cuts ur editor’s connection to the n8n process. the actual execution may still be running in the background even tho the editor shows reset data. check ur nginx config (or Hostinger’s proxy settings) for proxy_read_timeout + proxy_send_timeout and bump to 600s+. is the workflow execution actually failing, or just the editor view going null after the timeout hits?
Hi @Andrew_Parsons
You are running into a technical issue where n8n “forgets” its previous steps when a sub-workflow takes a long time to finish. To save computer memory during these long pauses, the system clears out the temporary data it was holding onto. When the sub-workflow finally completes and the main workflow wakes up, it tries to look back at those earlier steps, but finds that the information has been wiped out, leaving you with empty “null” values.
Instead of the messy workaround of passing every single detail back and forth, the best solution is to use a “permanent record” like a database or n8n’s Data Tables. You should save your important information in a table at the start and give it a unique ID. After the long sub-workflow finishes, the main workflow simply uses that ID to look up the information in the table, ensuring you always have access to your data without cluttering your workflow.
i think this is a pretty common issue on self hosted n8n.
Whats happening:
When the parent workflow pauses and waits for the sub workflow, it keeps that context data in memory (not the database). LLM calls take long enough that the process either times out or gets recycled on Hostinger, and that memory just gets wiped. So when the sub workflow finishes, the parent has nothing to come back to.
Try these fixes in order:
First, change your execution process mode to main:
EXECUTIONS_PROCESS=main
This alone fixes it for most people.
Second, make sure execution data is being saved to your database:
EXECUTIONS_DATA_SAVE_ON_SUCCESS=all
EXECUTIONS_DATA_SAVE_ON_ERROR=all
Third, bump up your timeout since LLM calls can easily run 30-90 seconds:
EXECUTIONS_TIMEOUT=300
EXECUTIONS_TIMEOUT_MAX=600
Also if you are still on SQLite, switching to Postgres makes a big difference on self hosted setups under any real load.
One more thing, your current workaround of passing values into the sub workflow and returning them back is actually a solid pattern that a lot of people use on purpose. But the fixes above, specially the process mode change, should stop the null context problem completely.
Start with EXECUTIONS_PROCESS=main
mark it answerand let me know if that helps
Thanks - I already had the =main, but added the others. Unfortunately no luck, so resorting to a Run Context Data table in my database to keep track of the data before and after calling sub-workflows.
Yeah - just seems like 60 seconds is low in today’s world with a single LLM call that can take minutes. I’m sure when the team built that duration in, they expected sub-workflows to be short, repeatable processes only taking a few seconds.
The workflow doesn’t fail, just the data context gets set to null in the parent. Using a more permanent data record in my database to track the data over the sub-workflow.
Yeah - fun innit? lol.
I was already going down the path of a more permanent record - a Run Context Data table in my database - so you’re giving me hope that I’m not being dumb. 