n8n workflows calling Mistral models time out on long completions because the default HTTP Request timeout is 300 seconds and Mistral's larger models can take longer for complex prompts. Fix this by increasing the HTTP Request node timeout, enabling streaming to get incremental responses, and splitting large prompts into smaller chunks to stay within safe completion times.
Why n8n Times Out on Long Mistral Completions
When you send complex prompts to Mistral's larger models (mistral-large, codestral) through n8n, the API can take 60-180 seconds to respond — sometimes longer for code generation or multi-step reasoning tasks. n8n's HTTP Request node has a default timeout of 300 seconds (5 minutes), but the actual bottleneck is often the workflow execution timeout, which defaults to 60 seconds on n8n Cloud and varies on self-hosted instances. This tutorial covers every timeout layer — node, workflow, and server — and shows how to configure each one, plus how to use streaming as an alternative to waiting for the full response.
Prerequisites
- A running n8n instance (self-hosted or cloud) on version 1.30 or later
- A Mistral API key configured as n8n credentials
- Basic understanding of n8n HTTP Request nodes
- Access to n8n environment variables (self-hosted) or workflow settings (cloud)
- Familiarity with the Mistral API documentation
Step-by-step guide
Identify which timeout is triggering the error
Identify which timeout is triggering the error
n8n has three timeout layers that can cause failures: (1) the HTTP Request node's own timeout, (2) the workflow execution timeout, and (3) the server-level execution timeout set via environment variables. Check the error message to identify the source. 'ETIMEDOUT' or 'socket hang up' means the HTTP Request node timed out. 'Workflow execution timed out' means the workflow-level limit was hit. 'The execution has timed out' with no node name means the server-level timeout fired. Each requires a different fix.
Expected result: You know which timeout layer caused the failure and can apply the correct fix below.
Increase the HTTP Request node timeout
Increase the HTTP Request node timeout
Open the HTTP Request node that calls the Mistral API. Go to Options (at the bottom of the node settings) and find the Timeout field. Set it to 600000 (600 seconds / 10 minutes). This is the maximum time the node will wait for a response from Mistral before throwing an ETIMEDOUT error. For most Mistral completions, 120-180 seconds is sufficient, but setting a generous timeout prevents failures on unusually complex prompts.
1// HTTP Request node configuration2// Method: POST3// URL: https://api.mistral.ai/v1/chat/completions4// Authentication: Header Auth5// Name: Authorization6// Value: Bearer {{ $credentials.mistralApi.apiKey }}7// Options:8// Timeout: 6000009// Retry On Fail: true10// Max Tries: 211// Wait Between Tries: 5000Expected result: The HTTP Request node waits up to 10 minutes for Mistral's response instead of timing out at the default.
Set the workflow execution timeout
Set the workflow execution timeout
Each workflow in n8n has its own execution timeout. Open Workflow Settings (gear icon in the top-right of the workflow editor) and set the Timeout Workflow After field to 900 seconds (15 minutes). This must be higher than your HTTP Request timeout to prevent the workflow from being killed while the node is still waiting for Mistral. On n8n Cloud, the maximum workflow timeout is 900 seconds on Pro plans.
Expected result: The workflow allows up to 15 minutes of total execution time, accommodating long Mistral completions plus any pre/post-processing steps.
Configure server-level timeout for self-hosted n8n
Configure server-level timeout for self-hosted n8n
If you are running n8n self-hosted, there is a server-level execution timeout controlled by environment variables. Set EXECUTIONS_TIMEOUT to -1 (unlimited) or a high value like 3600 (1 hour). Also set EXECUTIONS_TIMEOUT_MAX to the same value. These environment variables cap the maximum time any workflow can run, regardless of workflow-level settings. If these are set lower than your workflow timeout, they take precedence and will kill the execution.
1# Environment variables for self-hosted n8n2# Add to your .env file or Docker Compose environment34EXECUTIONS_TIMEOUT=36005EXECUTIONS_TIMEOUT_MAX=360067# For Docker Compose:8# environment:9# - EXECUTIONS_TIMEOUT=360010# - EXECUTIONS_TIMEOUT_MAX=3600Expected result: Server-level timeout allows workflows to run for up to 1 hour, sufficient for even the longest Mistral completions.
Implement streaming to avoid timeout issues entirely
Implement streaming to avoid timeout issues entirely
Instead of waiting for Mistral to generate the entire response, use streaming to receive tokens incrementally. Set stream: true in the Mistral API request body. The HTTP Request node will receive the response as a stream of Server-Sent Events (SSE). This keeps the connection alive and avoids timeout because data flows continuously. After receiving the streamed response, use a Code node to concatenate the chunks into the final response text.
1// HTTP Request node body (JSON) — enable streaming2{3 "model": "mistral-large-latest",4 "messages": [5 {6 "role": "system",7 "content": "You are a helpful coding assistant."8 },9 {10 "role": "user",11 "content": "{{ $json.prompt }}"12 }13 ],14 "max_tokens": 4096,15 "temperature": 0.2,16 "stream": true17}1819// Then in a Code node after the HTTP Request:20// Parse SSE stream into final text21const raw = $input.first().json.data || $input.first().binary?.data;22const text = String(raw);2324const chunks = text25 .split('\n')26 .filter(line => line.startsWith('data: ') && !line.includes('[DONE]'))27 .map(line => {28 try {29 const parsed = JSON.parse(line.replace('data: ', ''));30 return parsed.choices?.[0]?.delta?.content || '';31 } catch { return ''; }32 });3334const fullResponse = chunks.join('');35return [{ json: { response: fullResponse } }];Expected result: The workflow receives Mistral's response incrementally via streaming, keeping the connection alive and eliminating timeout errors.
Split large prompts to reduce completion time
Split large prompts to reduce completion time
If your prompts consistently trigger long completions (over 2 minutes), consider splitting the task into smaller sub-tasks. Use the SplitInBatches node to break a complex prompt into sequential simpler prompts. For example, instead of asking Mistral to generate an entire application in one request, ask it to generate one component at a time. Each sub-request completes faster and stays safely within timeout limits. Combine the results in a final Code node.
Expected result: Complex tasks are broken into smaller, faster API calls that each complete well within timeout limits.
Complete working example
1// Complete Code node: Parse Mistral streaming response2// Place after HTTP Request node with stream: true34const items = $input.all();5const results = [];67for (const item of items) {8 // Get the raw streamed response9 const rawResponse = item.json.data10 || item.json.body11 || JSON.stringify(item.json);12 const text = String(rawResponse);1314 // Parse SSE events15 const lines = text.split('\n');16 let fullContent = '';17 let tokenCount = 0;18 let model = '';19 let finishReason = '';2021 for (const line of lines) {22 if (!line.startsWith('data: ')) continue;23 if (line.includes('[DONE]')) continue;2425 try {26 const event = JSON.parse(line.slice(6));27 const delta = event.choices?.[0]?.delta;2829 if (delta?.content) {30 fullContent += delta.content;31 tokenCount++;32 }3334 if (!model && event.model) {35 model = event.model;36 }3738 if (event.choices?.[0]?.finish_reason) {39 finishReason = event.choices[0].finish_reason;40 }41 } catch (e) {42 // Skip malformed SSE lines43 }44 }4546 results.push({47 json: {48 response: fullContent,49 model,50 tokenCount,51 finishReason,52 streamed: true,53 complete: finishReason === 'stop'54 }55 });56}5758return results;Common mistakes when handling n8n Timeout Errors on Long Completions from Mistral
Why it's a problem: Setting the HTTP Request node timeout but not the workflow execution timeout
How to avoid: The workflow timeout takes precedence — set it higher than the node timeout in Workflow Settings
Why it's a problem: Using the default timeout on n8n Cloud and wondering why long Mistral calls fail
How to avoid: n8n Cloud has a 900-second max — use streaming or split prompts for tasks that take longer
Why it's a problem: Not setting max_tokens in the Mistral request, allowing unbounded generation
How to avoid: Always set max_tokens (e.g., 4096) to cap response length and prevent unexpectedly long completions
Why it's a problem: Retrying a timed-out request immediately without increasing the timeout first
How to avoid: Increase the timeout before enabling retries — retrying with the same timeout just burns API credits
Why it's a problem: Parsing the streamed response as JSON without handling SSE format (data: prefix, [DONE] marker)
How to avoid: Split by newlines, filter for 'data: ' prefix, skip [DONE], then JSON.parse each line
Best practices
- Set HTTP Request node timeout to at least 2x the expected Mistral response time
- Always set workflow timeout higher than the sum of all node timeouts
- Use streaming for any Mistral call that might take more than 60 seconds
- Enable Retry On Fail in the HTTP Request node with 2 retries and 5-second wait
- Monitor execution times in n8n's Execution History to set appropriate timeout thresholds
- Use max_tokens to cap response length and prevent unexpectedly long completions
- Add a Wait node with 1-second delay between sequential Mistral calls to avoid rate limits
- For self-hosted n8n, set EXECUTIONS_TIMEOUT via environment variables, not just workflow settings
Still stuck?
Copy one of these prompts to get a personalized, step-by-step explanation.
My n8n workflow calls Mistral's API for code generation but times out after 60 seconds. How do I increase timeouts at the node, workflow, and server level, and how do I implement streaming as an alternative?
I get ETIMEDOUT errors when calling mistral-large from an n8n HTTP Request node. How do I configure the timeout and enable streaming to handle long completions?
Frequently asked questions
What is the default HTTP Request node timeout in n8n?
The default timeout is 300 seconds (5 minutes). You can increase it in the node's Options section. The maximum depends on your workflow and server-level timeout settings.
Does enabling streaming in Mistral use more tokens or cost more?
No, streaming does not change the token count or pricing. It delivers the same response in incremental chunks instead of waiting for the full response. The total tokens generated are identical.
Why does my Mistral call take so long compared to OpenAI?
Mistral's larger models (mistral-large, codestral) can have higher latency for complex prompts, especially during peak usage. Response time depends on prompt complexity, max_tokens, and server load. Streaming helps mask this latency.
Can I set different timeouts for different nodes in the same workflow?
Yes, each HTTP Request node has its own timeout setting in its Options section. Set shorter timeouts for simple calls and longer ones for complex LLM completions.
What happens to a streamed response if the connection drops mid-stream?
The HTTP Request node will receive a partial response. Check the finish_reason field — if it is not 'stop', the response was cut off. Implement retry logic to re-request the completion.
Can RapidDev help optimize n8n workflows that call multiple LLM providers with different timeout requirements?
Yes, RapidDev builds production n8n workflows with provider-specific timeout handling, streaming, retry logic, and fallback chains. Their team can help configure the right timeout strategy for workflows that call Mistral, OpenAI, Claude, or other providers in sequence or parallel.
Talk to an Expert
Our team has built 600+ apps. Get personalized help with your project.
Book a free consultation