How to Fix Random Language Model Failures in n8n When Triggered by Webhook

By default, n8n stops the entire workflow when a node errors. For LLM nodes triggered by webhooks, this means a single API failure kills the webhook response and returns a generic error to the caller. Change the On Error setting on your LLM node from Stop Workflow to Continue (using error output). This adds a second output connector on the node: the main output for successful responses and the error output for failures. Connect the error output to a separate branch that handles failures, such as retrying the request or returning a fallback response to the webhook caller. This prevents transient API errors from crashing the workflow.

Create a retry mechanism for transient LLM failures. The simplest approach in n8n is to use the Execute Workflow node to call a sub-workflow that contains the LLM call. On the error output of the LLM node in the sub-workflow, add a Code node that increments a retry counter and calculates the wait time using exponential backoff. Then use a Wait node with the calculated delay before routing back to the LLM node. After a maximum number of retries (typically 3), route to a final failure handler. The parent workflow receives either the successful response or the final failure result.

1// Code node: Retry Controller
2// Place on the error output of the LLM node
3
4const item = $input.first();
5const retryCount = (item.json.retryCount || 0) + 1;
6const maxRetries = 3;
7
8// Exponential backoff: 2s, 4s, 8s
9const waitSeconds = Math.pow(2, retryCount);
10
11const errorCode = item.json.error?.httpCode
12  || item.json.error?.code
13  || 'unknown';
14
15// Only retry on transient errors
16const retriableErrors = [429, 500, 502, 503, 'ETIMEDOUT', 'ECONNRESET'];
17const isRetriable = retriableErrors.includes(errorCode)
18  || retriableErrors.includes(Number(errorCode));
19
20return [{
21  json: {
22    ...item.json,
23    retryCount: retryCount,
24    waitSeconds: waitSeconds,
25    shouldRetry: isRetriable && retryCount <= maxRetries,
26    giveUp: retryCount > maxRetries || !isRetriable,
27    errorCode: errorCode
28  }
29}];

When multiple webhook requests arrive simultaneously, they all trigger LLM API calls at the same time, which can exceed your rate limit. Implement a queuing pattern by setting concurrency limits on your n8n instance or workflow. In n8n self-hosted, set the environment variable EXECUTIONS_CONCURRENCY to limit how many workflows run simultaneously (e.g., 5). For finer control, use the n8n queue mode with Redis to distribute executions across worker processes. On n8n Cloud, the concurrency is managed by your plan tier. Additionally, within a single workflow, if you process multiple items, use SplitInBatches with a batch size of 1 and add a Wait node with a short delay between batches to space out API calls.

1// Environment variable for self-hosted n8n:
2// EXECUTIONS_CONCURRENCY=5
3
4// Or set per-workflow concurrency in workflow settings:
5// Settings > Workflow Settings > Concurrency > Max Concurrent Executions

If your LLM call takes more than a few seconds, the webhook caller may time out waiting for a response. Separate the webhook acknowledgment from the LLM processing by immediately returning a 202 Accepted response with a processing ID, then processing the LLM call asynchronously. Use the Respond to Webhook node right after the Webhook node to send the immediate acknowledgment. Then continue the workflow to the LLM node. When the LLM finishes, use an HTTP Request node to send the result to a callback URL provided by the caller. This async pattern prevents timeout errors and improves the caller's experience.

1// Webhook → Code node (generate processing ID) → Respond to Webhook (202) → LLM node → HTTP Request (callback)
2
3// Code node: Generate Processing ID
4const processingId = $execution.id;
5const callbackUrl = $json.body?.callbackUrl || null;
6
7return [{
8  json: {
9    processingId: processingId,
10    callbackUrl: callbackUrl,
11    userMessage: $json.body?.message || '',
12    // Response for immediate webhook reply
13    webhookResponse: {
14      status: 'processing',
15      processingId: processingId,
16      message: 'Your request is being processed.'
17    }
18  }
19}];
20
21// Respond to Webhook node settings:
22// Response Code: 202
23// Response Body: {{ $json.webhookResponse }}

Create a separate workflow that monitors LLM failures across all your webhook-triggered workflows. Add an Error Trigger node as the start of this monitoring workflow. In your main workflow settings, set the Error Workflow to point to this monitoring workflow. When any execution fails (after retries are exhausted), the Error Trigger captures the failure details including the workflow name, execution ID, error message, and the input data. Connect the Error Trigger to a Slack, Email, or database node that logs the failure for review. This gives you visibility into failure patterns and helps identify systemic issues like API key expiration or provider outages.

1// Error monitoring workflow structure:
2// Error Trigger → Code node (format alert) → Slack/Email
3
4// Code node: Format Error Alert
5const error = $input.first().json;
6
7const alert = {
8  text: `LLM Failure Alert`,
9  blocks: [
10    {
11      type: 'header',
12      text: { type: 'plain_text', text: 'Workflow Failure' }
13    }
14  ],
15  // For Slack message
16  slackMessage: [
17    `*Workflow:* ${error.workflow?.name || 'Unknown'}`,
18    `*Execution:* ${error.execution?.id || 'Unknown'}`,
19    `*Error:* ${error.message || 'No message'}`,
20    `*Time:* ${new Date().toISOString()}`
21  ].join('\n')
22};
23
24return [{ json: alert }];

After retries are exhausted, the workflow should still return a meaningful response to the webhook caller instead of an error or timeout. On the final failure branch (after the retry logic gives up), add a Respond to Webhook node that returns a friendly error message with the appropriate HTTP status code. Include a reference ID (the execution ID) so the user can report the issue. Store the failed request data in a database or queue for later manual processing or automatic retry by a scheduled workflow. This ensures no user request is silently lost.

1// Code node: Build Fallback Response
2const item = $input.first().json;
3
4return [{
5  json: {
6    httpCode: 503,
7    response: {
8      status: 'error',
9      message: 'Our AI service is temporarily unavailable. Please try again in a few minutes.',
10      referenceId: $execution.id,
11      retryAfter: 60
12    },
13    // Data to save for later retry
14    failedRequest: {
15      originalMessage: item.userMessage || item.chatInput || '',
16      sessionId: item.sessionId || '',
17      error: item.error || 'Unknown error',
18      retryCount: item.retryCount || 0,
19      timestamp: new Date().toISOString()
20    }
21  }
22}];