How to retry failed workflows in n8n?

The simplest and most reliable way to retry failed workflows in n8n is to enable ‘Continue On Fail’ on nodes where failure is expected, and for full‑workflow retries you should configure an Error Workflow that receives the failed execution, analyzes why it failed, and then manually restarts the original workflow using the n8n API (usually via the Workflow Trigger node or the HTTP Request node). This avoids looping failures and gives you production‑level control.

 

What “retrying failed workflows” really means in n8n

 

n8n does NOT automatically re-run a workflow if it fails. A workflow run is static: once it fails, it’s done. You can:

• retry a step inside a workflow (node-level retry)
• retry the entire workflow execution (usually with an Error Workflow)
• manually re-run from the UI, which is not suitable for production

In production, you use a combination of node-level retry and Error Workflows.

 

Option A — Node-Level Retry (most common)

 

Use this when the failure is expected (for example, an API might occasionally return 429 or 500). n8n gives you a setting called Retry On Fail directly inside the node.

• Open the node
• Scroll to Error Handling
• Enable Retry On Fail
• Set delay and max attempts

This prevents the workflow from failing in the first place. It’s perfect for unstable APIs.

 

Option B — “Continue On Fail” + Manual Logic

 

Enable Continue On Fail if you don’t want the workflow to stop. The node will output an error object instead of crashing the run. You can then create your own logic, such as:

• Check if the error is retryable
• Wait X seconds
• Try again with another HTTP Request node

This gives you full control but requires more workflow design.

 

Option C — Error Workflow (for full-workflow retries)

 

This is the real way to retry a failed workflow execution in production. n8n lets you define one workflow as an Error Workflow. Any other workflow that fails will send an execution dump to that error workflow.

How this works in practice:

• Create a new workflow
• Add the Error Trigger
• This workflow will receive:
  • the failed workflow ID
  • the execution ID
  • error message
  • node that failed
  • input/output data snapshot

You can then use an HTTP Request node to restart the workflow using n8n’s REST API.

 

// Example payload you send to rerun a workflow
{
  "workflowId": 123,
  "runData": {
    "manual": true
  }
}

 

This requires that you enable n8n’s REST API and use an API Key or Basic Auth.

The Error Workflow approach is best when you want:

• retries with backoff
• alerting + retry
• logic to decide if retry is even safe

 

Important: Use a “Retry Count” storage

 

To avoid infinite loops (failing → Error Workflow → retry → failing…), store a retry counter. You can use:

• Workflow Data (static data)
• External DB (Postgres/MySQL/Airtable/etc.)
• n8n's built-in static data for simple cases

Check the counter before restarting. If it exceeds your limit, stop and notify someone.

 

Option D — Manually retry from Executions UI

 

Inside the n8n UI, you can open a failed execution and click “Retry”. This re-runs the workflow from the start with the same input data. Great for debugging, not for production automation.

 

When NOT to retry

 

Sometimes retrying makes things worse (for example, duplicate payments, repeated form submissions). Always understand what the workflow is doing before implementing automated retries.

 

Summary

 

• Use Retry On Fail for simple API hiccups.
• Use Continue On Fail when you want custom retry logic inside the workflow.
• Use an Error Workflow to retry entire failed workflows safely.
• Use Retry Count to avoid infinite loops.
• Manual retry is available, but not for automation.

This combination gives you stable, production‑grade retry handling in n8n.