How to Retry Failed Workflows in n8n

Open the Executions tab from the left sidebar or from within the specific workflow's editor. Filter by Error status to see only failed executions. Click on the failed execution to open its details. You will see the workflow with the error highlighted on the node that failed. At the top of the execution view, click the Retry button. n8n gives you two options: Retry with original workflow (uses the workflow version from the time of the original execution) or Retry with current workflow (uses the latest saved version). Choose the option that fits your situation.

For nodes that interact with external APIs (like HTTP Request, OpenAI, or database nodes), you can configure automatic retries. Open the node settings by clicking the node, then go to the Settings tab. Toggle on Retry On Fail. Set the Max Tries (how many times to retry, typically 2-3), and the Wait Between Tries in milliseconds (start with 1000ms and increase for rate-limited APIs). When this node fails, n8n automatically retries it before marking the execution as failed.

Each node has an On Error setting under the Settings tab with three options: Stop Workflow (default), Continue (outputs error data to the next node), and Continue (using error output). The third option creates a second output on the node — one for success, one for errors. Connect the error output to a separate branch that handles the failure, such as sending a notification or logging the error. This way, a single node failure does not stop the entire workflow.

Create a separate workflow that starts with an Error Trigger node. This node fires whenever any workflow in your n8n instance fails (or you can scope it to specific workflows). The Error Trigger receives the error details including the workflow ID, execution ID, and error message. Connect it to nodes that send notifications (like email or Slack) and optionally to an Execute Workflow node that re-runs the failed workflow. This gives you a centralized error handling and retry system.

For more control over retry behavior, including exponential backoff, implement retry logic in a Code node. This approach wraps an HTTP request in a retry loop that waits progressively longer between attempts. Use this when the built-in Retry On Fail settings do not offer enough control, such as when you need exponential backoff, different retry strategies per error code, or custom logging between retries.

1// Code node: HTTP request with exponential backoff
2// Mode: Run Once for All Items
3
4const MAX_RETRIES = 3;
5const BASE_DELAY_MS = 1000;
6
7async function fetchWithRetry(url, options, retries = 0) {
8  try {
9    const response = await this.helpers.httpRequest({
10      method: 'POST',
11      url: url,
12      body: options.body,
13      headers: options.headers,
14      returnFullResponse: true
15    });
16    return response;
17  } catch (error) {
18    if (retries >= MAX_RETRIES) {
19      throw error;
20    }
21    const statusCode = error.statusCode || 0;
22    // Only retry on transient errors
23    if ([429, 500, 502, 503, 529].includes(statusCode)) {
24      const delay = BASE_DELAY_MS * Math.pow(2, retries);
25      await new Promise(r => setTimeout(r, delay));
26      return fetchWithRetry.call(this, url, options, retries + 1);
27    }
28    throw error; // Non-retryable error
29  }
30}
31
32const items = $input.all();
33const results = [];
34
35for (const item of items) {
36  const response = await fetchWithRetry.call(
37    this,
38    item.json.apiUrl,
39    {
40      body: item.json.requestBody,
41      headers: { 'Content-Type': 'application/json' }
42    }
43  );
44  results.push({ json: { ...item.json, response: response.body } });
45}
46
47return results;