- Out of the box, there's no timeout
- The settings that control execution limits
- How the default and the ceiling work together
- Picking a timeout per kind of workflow
- AI and LLM nodes have their own timer
- Keeping execution history under control
- These only apply where you control the config
- How Make limits a scenario
- My advice for self-hosters
- Frequently asked questions
In n8n, EXECUTIONS_TIMEOUT sets a default timeout in seconds, after which a workflow execution is stopped. Its default is -1, which turns the timeout off. Users can override it per workflow up to EXECUTIONS_TIMEOUT_MAX, which defaults to 3600 seconds. Both are environment variables you set on a self-hosted instance.
Out of the box, there's no timeout
This surprises people who expect a safety net. On a self-hosted n8n instance, EXECUTIONS_TIMEOUT defaults to -1, and -1 disables the timeout. So a workflow stuck waiting on a slow API, or caught in a loop, will keep running until something else stops it. If you run n8n for clients or for your own business, setting a default timeout is one of the first things worth doing.
The settings that control execution limits
| Variable | Default | What it controls |
|---|---|---|
| EXECUTIONS_TIMEOUT | -1 (disabled), in seconds | Default timeout for every workflow |
| EXECUTIONS_TIMEOUT_MAX | 3600 seconds | Highest timeout a user can set for one workflow |
| N8N_AI_TIMEOUT_MAX | 3600000 milliseconds | HTTP request timeout for AI and LLM nodes |
| N8N_CONCURRENCY_PRODUCTION_LIMIT | -1 (disabled in regular mode) | Production executions running at the same time |
| EXECUTIONS_MODE | regular | Whether executions run in regular or queue mode |
Note the units. The two execution timeouts are in seconds; the AI timeout is in milliseconds, so 3600000 is the same hour as 3600 seconds. Mixing them up is the easiest way to set a timeout a thousand times too short or too long.
How the default and the ceiling work together
EXECUTIONS_TIMEOUT is the default every workflow gets. Users can then override the timeout for an individual workflow, but only up to EXECUTIONS_TIMEOUT_MAX. So if you set a default of five minutes and leave the ceiling at its 3600-second default, a user can give one heavy reporting workflow up to an hour, but no more.
A typical setup for a small business instance might be:
EXECUTIONS_TIMEOUT=300so most workflows stop after five minutes if something hangs.EXECUTIONS_TIMEOUT_MAX=3600, the default, so long jobs can be given up to an hour.
Then raise the timeout only on the workflows that need it, such as a nightly export.
Picking a timeout per kind of workflow
| Kind of job | Sensible timeout | Why |
|---|---|---|
| Form or webhook responder | A minute or two | Should finish fast; a long run means something's stuck |
| Routine sync between apps | The default, a few minutes | Catches hung API calls without cutting normal runs |
| Nightly export or report | Up to the ceiling | Large data sets need room |
These are starting points to adjust once you've seen how long your real runs take.
AI and LLM nodes have their own timer
N8N_AI_TIMEOUT_MAX sets the HTTP request timeout for AI and LLM nodes such as OpenAI, Anthropic, Mistral and Ollama, and defaults to 3600000 milliseconds. That's separate from the workflow timeout. If a workflow's overall timeout is shorter than a slow AI call, the workflow timeout will stop it first, so set them with each other in mind. My guide to building AI agents in n8n covers where those long calls usually come from.
Keeping execution history under control
Timeouts aren't the only execution limits worth knowing. n8n also manages how much history it keeps:
- EXECUTIONS_DATA_PRUNE defaults to true, so old execution data is cleared out.
- EXECUTIONS_DATA_MAX_AGE defaults to 336 hours, which is two weeks.
- EXECUTIONS_DATA_PRUNE_MAX_COUNT keeps up to 10000 executions in the database by default; 0 means no limit.
- EXECUTIONS_DATA_MAX_DISPLAY_SIZE defaults to 104857600 bytes. Bigger executions show as too large to display, but can still be retried or resumed.
If you need execution data stored in s3 or azure instead, those storage modes require a self-hosted Business or Enterprise plan.
These only apply where you control the config
The n8n Docs page on executions environment variables is clear on the catch. By default there's no timeout at all, and when you do set one, a user can only raise an individual workflow up to EXECUTIONS_TIMEOUT_MAX. These are environment variables, so they apply where you control the n8n configuration, such as your own server or container, not in a hosted account's settings page. If you're on a hosted plan, check that plan's own documentation rather than assuming these defaults.
Want AI doing the heavy lifting in your marketing?
I build the systems that handle the boring 80 percent, so you get your week back. Done properly, with the human kept in.
How Make limits a scenario
Make's scenario settings include a Cycles per run setting, which defines the maximum number of cycles allowed during a scenario execution. For a wider comparison, see my guides to n8n and Zapier and workflow automation tools.
My advice for self-hosters
Set EXECUTIONS_TIMEOUT to a few minutes on day one, leave the ceiling at an hour, and only raise individual workflows that need it. Check the AI timeout's units, keep pruning on, and you'll avoid the slow creep of stuck runs and a bloated database.
Want your tool on this list? Featured spots and reviews here are paid partnerships. Here's how to partner with me.
Frequently asked questions
What's the default n8n execution timeout?
-1, which disables the timeout.
What's the maximum timeout a workflow can set?
EXECUTIONS_TIMEOUT_MAX, 3600 seconds by default.
Is the AI node timeout separate?
Yes. It's N8N_AI_TIMEOUT_MAX, 3600000 milliseconds by default.
How long does n8n keep execution data?
EXECUTIONS_DATA_MAX_AGE defaults to 336 hours when pruning is on.
How many executions can run at once?
That's controlled by N8N_CONCURRENCY_PRODUCTION_LIMIT.
