How to Fix 'Workflow Execution Failed' Error in n8n

The n8n execution log — your first stop for every "Workflow Execution Failed" error.

I remember the first time I saw "Workflow Execution Failed" on a production server at 2 AM. My heart sank. I had no idea where to start. After 3 hours of debugging, I found the issue — a missing OAuth refresh token. That night taught me the systematic approach I am sharing with you today.

Short on time? Pick your error from the table of contents below and jump straight to the fix. I have debugged this error across self-hosted Docker instances, Oracle Cloud VPSes, n8n Cloud, and Railway deployments. The error always has a specific cause — but you have to know where to look and what to look for. This guide gives you a systematic approach to find the real error in under two minutes and apply the exact fix it needs.

Step 0: How to Actually Read n8n's Execution Log

Before diving into fixes, you need to master the execution log. This is the tool that turns "Workflow Execution Failed" — a useless message on its own — into a specific, actionable error you can fix in minutes. I have debugged this error repeatedly across self-hosted Docker instances, Oracle Cloud VPSes, n8n Cloud, and Railway deployments. In the large majority of cases, the fix takes under 5 minutes once you know where to look.

The Five-Step Debugging Process

Fig 1. The execution log — the red node shows exactly where the failure occurred. Click it to read the real error.

The single most common debugging mistake in n8n is trying to fix the workflow without first reading the execution log. The log gives you a specific error message in the large majority of cases. Always start there — it takes 20 seconds and eliminates hours of guessing. — William Ayadi, TriggerWorkflow

Error Message Quick-Reference Table

Fix #1: Node Timeout Errors

n8n enforces execution time limits on every node. An HTTP Request node that waits for a slow API, a Wait node set to too long a duration, or a Code node with an infinite loop — all trigger a timeout that kills the execution.

Identifying a Timeout Error

The error message will contain: ETIMEDOUT, ESOCKETTIMEDOUT, socket hang up, or simply timeout. The node type is almost always HTTP Request, Wait, or Code.

Fix for HTTP Request Node Timeouts

Open the HTTP Request node → Options tab → set Timeout to 60000 (60 seconds) or 120000 (120 seconds). The default is 10000ms (10 seconds) — too short for any AI API or slow third-party service.

Fig 2. Set the Timeout field in HTTP Request node Options. Default 10s is too short for AI APIs — use 60-120s.

Fix for Global Execution Timeout (Self-Hosted)

Add this to your .env file or Docker environment, then restart n8n:

# Default is 3600 seconds (1 hour). Increase for long-running workflows.
EXECUTIONS_TIMEOUT=7200
EXECUTIONS_TIMEOUT_MAX=10800

# For HTTP Request node specifically:
N8N_DEFAULT_TIMEOUT=120000   # in milliseconds

Fix #2: Expression Errors (The Most Common Cause)

Expression errors are the single most frequent cause of execution failures in n8n. They happen when you reference a field that does not exist, use the wrong variable, or write a JavaScript expression with a type error.

The Three Expression Error Patterns

Defensive Expression Patterns for Production

// Safe string field access with fallback
{{ $json.customer?.name ?? 'Unknown Customer' }}

// Safe nested access — won't crash if address is null
{{ $json.customer?.address?.city ?? 'No City' }}

// Safe number conversion
{{ Number($json.price) || 0 }}

// Safe array length check
{{ Array.isArray($json.items) ? $json.items.length : 0 }}

// Safe date formatting
{{ $json.created_at ? new Date($json.created_at).toISOString() : new Date().toISOString() }}

Fix #3: Credential Errors (Expired OAuth and Wrong Keys)

Credential errors produce 401 or 403 HTTP responses, or provider-specific messages like invalid_grant, access_token_expired, or invalid API key. They are extremely common in long-running automations because OAuth tokens expire.

How OAuth Tokens Expire in n8n

Google, Microsoft, Slack, and most OAuth2 services issue short-lived access tokens (typically 1 hour) and long-lived refresh tokens (months to years). n8n automatically refreshes access tokens using the refresh token. But if:

• The user revokes n8n's access in their Google Account settings
• The refresh token itself expires (Google expires refresh tokens after 6 months of non-use)
• The OAuth app is deleted or its scopes are changed

...then n8n cannot refresh the token and every execution using that credential fails with a 401 error. For the official list of credential types and setup requirements, see the n8n credentials documentation.

Fix: Re-authenticate the Credential

Go to n8n Settings → Credentials → find the failing credential → click Reconnect (for OAuth2) or update the API key. For Google credentials, you may need to fully revoke and re-authorize.

Fix #4: Data Type Mismatches and API Request Errors

n8n passes data between nodes as JSON objects. When a node receives data in the wrong format — a string where a number is expected, an object where an array is required, or a null where a non-null value is mandatory — the execution fails.

One of the most common searches I see is "n8n check url node success error output". This happens when the HTTP Request node returns a 200 OK but the body is empty or contains an error. The fix is to add a Code node after the HTTP Request to validate the response body — see the example below.

Type Conversion in a Code Node

// String → Number (price field from Typeform often comes as string)
const price = parseFloat($input.item.json.price_text) || 0;

// Number → String (for Telegram message formatting)
const priceStr = price.toFixed(2);

// Object → JSON string (for HTTP Request body that expects a string)
const payload = JSON.stringify({ amount: price, currency: 'USD' });

// Comma-separated string → Array (Typeform checkbox answers)
const tags = ($input.item.json.tags_csv || '').split(',').map(t => t.trim()).filter(Boolean);

return [{
  json: {
    price_number: price,
    price_string: priceStr,
    tags_array: tags,
    api_payload: payload
  }
}];

Missing Required Fields in API Calls

When calling any external API (Stripe, OpenAI, Shopify, HubSpot), a 400 or 422 response means the API rejected your request because a required field is missing or invalid. The fix process:

1. Open the failing HTTP Request node and click the Output panel in the failed execution. The response body will list the exact missing field.
2. Open the API's official documentation and verify the required fields for that endpoint.
3. Add an IF node before the API call to validate that all required fields are present and non-empty before sending the request.

For a deeper dive into this specific issue, see the dedicated guide: n8n Check URL Node: How To Fix Success Error & Execution Timeout.

Fix #5: API Rate Limiting (429 Errors)

A 429 error means you are sending requests faster than the API allows. OpenAI, Google, Stripe, and every major API provider enforces rate limits. In n8n, this typically happens when a workflow loops over many items and calls an API for each one without any delay.

The Rate Limit Fix Toolkit

The three-layer approach to prevent rate limit failures:

• Layer 1 — Wait node: Add a Wait node (1–2 seconds) between loop iterations to space out API calls. Simple and effective for moderate volumes.
• Layer 2 — Retry on Fail: On the HTTP Request or AI node, enable Retry on Fail (Options → Retry on Fail → 3 retries, 5 seconds wait). n8n will automatically retry 429 responses with a delay.
• Layer 3 — Split in Batches: Use the Split in Batches node to process items in groups of 5 or 10, with a Wait node between batches. This is the most reliable approach for bulk operations.

Correct node order for rate-limit-safe batch processing:

[Trigger] → [Split in Batches: size=5] → [HTTP Request / AI node]
                    ↑                              ↓
                    └──── [Wait: 2 seconds] ←──────┘

Split in Batches node settings:
  Batch Size: 5          (process 5 items at once)
  Reset: false           (continue from where it left off on retry)

Wait node settings:
  Amount: 2
  Unit: Seconds

Fix #6: Code Node JavaScript Errors

The Code node gives you full JavaScript inside n8n — which is powerful, but also means JavaScript errors can crash your workflow. The most common mistakes come from incorrect return format, missing semicolons, or using async functions without await.

The Correct Code Node Return Format

// ❌ WRONG — returning a plain object crashes the workflow
return { name: 'Alice', email: '[email protected]' };

// ❌ WRONG — returning an object inside json but not in an array
return { json: { name: 'Alice' } };

// ✅ CORRECT — must return an array of objects, each with a json key
return [{ json: { name: 'Alice', email: '[email protected]' } }];

// ✅ CORRECT — processing multiple input items
return $input.all().map(item => ({
  json: {
    name: item.json.name,
    email: item.json.email?.toLowerCase() ?? 'unknown'
  }
}));

// ✅ CORRECT — error handling with try-catch
try {
  const parsed = JSON.parse($input.item.json.raw_data);
  return [{ json: { parsed_data: parsed, success: true } }];
} catch (error) {
  return [{ json: { error: error.message, success: false, raw: $input.item.json.raw_data } }];
}

Debugging Code Node Errors

Add console.log() statements to inspect values at runtime. The output appears in your server logs. For Docker: docker logs n8n --tail 30 --follow. For systemd: journalctl -u n8n -f.

Fix #7: Memory and Resource Exhaustion (Self-Hosted)

On self-hosted n8n instances, workflows that process large files or loop over thousands of items can exhaust available memory. When this happens, the OS kills the n8n process mid-execution. The workflow shows "Execution Failed" with no node-level error — because the entire process died.

Symptoms of Memory-Related Failures

• Server logs show Killed or OOMKilled immediately after execution failure.
• Docker shows OOM killer invoked in system logs (dmesg | grep -i oom).
• Execution fails on large datasets but works perfectly on small test sets.
• n8n restarts itself automatically after the failure.

The Three-Layer Fix for Memory Issues

1. Increase Node.js heap size: Add NODE_OPTIONS=--max-old-space-size=2048 to your environment variables. This gives Node.js 2GB of heap. Restart n8n after adding.
2. Batch large datasets: Use the Split in Batches node to process items in groups of 50–100 instead of all at once. This keeps memory usage flat regardless of dataset size.
3. Upgrade VPS RAM: Minimum recommended RAM for production n8n is 2GB. For workflows processing files or images, 4GB is better. Oracle Cloud free tier offers 1GB — sufficient for light workflows, insufficient for heavy processing.

# Increase Node.js heap (in MB) — add to .env or Docker environment
NODE_OPTIONS=--max-old-space-size=2048

# Limit concurrent executions to prevent memory spikes
EXECUTIONS_PROCESS=main
N8N_CONCURRENCY_PRODUCTION_LIMIT=10

# Apply changes:
# Docker: docker compose down && docker compose up -d
# systemd: sudo systemctl restart n8n

Fix #8: Sub-Workflow and Execute Workflow Failures

When you use the Execute Workflow node to call another workflow, a failure in the child workflow propagates back to the parent and shows as "Workflow Execution Failed" in the parent's execution log. The real error is inside the child workflow's execution, not the parent's.

How to Find the Real Error in a Sub-Workflow

1. Note the execution ID shown in the parent's failing Execute Workflow node output.
2. Go to the Executions list, filter by the child workflow's name, and find the execution with that ID.
3. Open the child execution log and find the red-bordered node there — that is the real error.

Fix #9: Silent Failures (No Error Message At All)

The hardest case: the execution shows red, but every node appears green when you open it, and the Error tab is empty. This is a silent failure, and it is the one gap most n8n troubleshooting guides skip entirely.

The Three Most Common Causes

1. The trigger itself failed before any node ran. Check the Trigger node's own execution history separately — Webhook and Schedule triggers can fail silently if the underlying service (Blogger, a third-party webhook sender) never delivered a valid payload.
2. The process was killed externally (VPS out-of-memory, a Docker restart policy, or a hosting provider's maintenance window) mid-execution, before n8n could write an error to the node. Check dmesg or your hosting provider's status page for the exact timestamp of the failed execution.
3. A workflow-level setting silently swallowed the error. If Continue on Fail is enabled on the last node in the chain, the workflow can report "success" or an empty failure with no visible cause. Audit every node's Settings tab for this option.

n8n Cloud vs Self-Hosted: Does This Guide Apply to You?

Most troubleshooting content online is written for one hosting type and silently assumes you are using the other. Here is exactly where this guide's fixes apply:

If you are on n8n Cloud and hit a silent failure with no server logs to check, your two remaining tools are the Error Logger workflow (below) and n8n's own support channel, since you cannot inspect the underlying process yourself.

Proactive Measures: How to Prevent "Workflow Execution Failed" Before It Happens

While fixing errors is essential, preventing them is even better. The following best practices will reduce the frequency of execution failures in your n8n workflows.

1. Always Validate Incoming Data

Add an IF node or Code node at the start of every workflow to check that required fields exist and are of the correct type. This is especially critical for webhook triggers where the incoming payload structure can vary unpredictably.

2. Use "Continue on Fail" for Non-Critical Paths

For HTTP Request nodes that call external APIs, enable Continue on Fail in the node's Settings. Then connect an IF node to check for errors and route the execution accordingly (e.g., log the error and continue with a fallback instead of failing the whole workflow).

3. Implement Idempotency

Design workflows so that re-running them does not duplicate actions. For example, use unique IDs to check if an order has already been processed before sending a confirmation email. This prevents duplicate operations that can cause downstream errors.

4. Set Up a Staging Environment

Test new workflows in a separate n8n instance or using test data before deploying them to production. This is particularly important for workflows that modify data or send real notifications.

5. Monitor Execution Trends

Use the Error Logger workflow from this article to track failures over time. If you see a sudden spike in a particular error type, investigate immediately — it may indicate a change in an external API or a credential about to expire.

Free Download: Automatic Error Logger Workflow

Instead of discovering workflow failures hours later, deploy this Error Trigger workflow to log every failure to Google Sheets and send you an instant Telegram alert. Import it once and it monitors all your workflows automatically.

{
  "name": "Error Logger — Telegram + Google Sheets",
  "nodes": [
    {
      "parameters": {},
      "name": "Error Trigger",
      "type": "n8n-nodes-base.errorTrigger",
      "typeVersion": 1,
      "position": [240, 300]
    },
    {
      "parameters": {
        "assignments": {
          "assignments": [
            {
              "id": "1",
              "name": "workflow_name",
              "value": "={{ $json.workflow.name }}",
              "type": "string"
            },
            {
              "id": "2",
              "name": "error_message",
              "value": "={{ $json.execution.error.message ?? 'Unknown error' }}",
              "type": "string"
            },
            {
              "id": "3",
              "name": "node_name",
              "value": "={{ $json.execution.error.node?.name ?? 'Unknown node' }}",
              "type": "string"
            },
            {
              "id": "4",
              "name": "execution_id",
              "value": "={{ $json.execution.id }}",
              "type": "string"
            },
            {
              "id": "5",
              "name": "failed_at",
              "value": "={{ new Date().toISOString() }}",
              "type": "string"
            }
          ]
        },
        "options": {}
      },
      "name": "Format Error Data",
      "type": "n8n-nodes-base.set",
      "typeVersion": 3,
      "position": [460, 300]
    },
    {
      "parameters": {
        "chatId": "YOUR_TELEGRAM_CHAT_ID",
        "text": "🔴 *n8n Workflow Failed*\n\n📋 Workflow: {{ $json.workflow_name }}\n⚠️ Error: {{ $json.error_message }}\n🔧 Node: {{ $json.node_name }}\n🆔 Execution: {{ $json.execution_id }}\n🕐 Time: {{ $json.failed_at }}",
        "additionalFields": { "parse_mode": "Markdown" }
      },
      "name": "Telegram Alert",
      "type": "n8n-nodes-base.telegram",
      "typeVersion": 1,
      "position": [680, 220],
      "credentials": { "telegramApi": { "id": "YOUR_TELEGRAM_CREDENTIAL_ID" } }
    },
    {
      "parameters": {
        "operation": "append",
        "documentId": { "value": "YOUR_GOOGLE_SHEET_ID", "mode": "id" },
        "sheetName": { "value": "Error Log", "mode": "name" },
        "columns": {
          "mappingMode": "defineBelow",
          "value": {
            "Workflow": "={{ $json.workflow_name }}",
            "Error": "={{ $json.error_message }}",
            "Node": "={{ $json.node_name }}",
            "Execution ID": "={{ $json.execution_id }}",
            "Timestamp": "={{ $json.failed_at }}"
          }
        },
        "options": {}
      },
      "name": "Log to Google Sheets",
      "type": "n8n-nodes-base.googleSheets",
      "typeVersion": 4,
      "position": [680, 400],
      "credentials": { "googleSheetsOAuth2Api": { "id": "YOUR_GOOGLE_CREDENTIAL_ID" } }
    }
  ],
  "connections": {
    "Error Trigger": { "main": [[{ "node": "Format Error Data", "type": "main", "index": 0 }]] },
    "Format Error Data": {
      "main": [[
        { "node": "Telegram Alert",     "type": "main", "index": 0 },
        { "node": "Log to Google Sheets", "type": "main", "index": 0 }
      ]]
    }
  },
  "active": false,
  "settings": { "executionOrder": "v1" }
}

Frequently Asked Questions

Continue Learning on TriggerWorkflow

If you found this guide useful, here are more articles to help you master n8n automation: