🚨 Automation Error Guide: 'Node execution failed' n8n ECONNRESET / 401 Credential

Overview

An n8n “node execution failed” error means a node — most often an HTTP Request or a service node — threw during execution and stopped the workflow run. The two most common underlying causes are a transport-level ECONNRESET (the peer reset the TCP connection mid-request) and a 401 Unauthorized returned because the node’s stored credential is wrong, expired, or its OAuth token failed to refresh. The execution is marked failed and, unless error handling is configured, the downstream nodes never run.

You will see this in the execution log / node error panel:

NodeApiError: The service refused the connection - perhaps it is offline
    error: read ECONNRESET
    at ClientRequest.<anonymous> (.../HttpRequestV3.node.ts)

Or the credential case:

NodeApiError: Authorization failed - please check your credentials
    httpCode: '401'
    response: { "error": "invalid_token", "error_description": "token expired" }

It occurs when the node actually runs — on a manual test, a scheduled trigger, or a webhook-driven execution. A node that worked last week can fail the moment a token expires, an upstream closes idle keep-alive connections, or the target tightens TLS.

Symptoms

• A node shows red with “Node execution failed” and the run is marked error.
• HTTP Request node reports read ECONNRESET or socket hang up.
• A service/credential node reports 401, invalid_token, or “Authorization failed”.
• Failures are intermittent (ECONNRESET) or sudden and total (expired credential).

# Inspect recent failed executions via the n8n CLI
n8n executions:list --status error 2>/dev/null | head

ID      Workflow            Status   Started
40213   Sync Orders -> CRM  error    2026-06-23T13:02:11Z

# Pull the error detail for one execution
n8n export:execution --id 40213 --output /tmp/exec.json 2>/dev/null
jq '.data.resultData.error | {message, httpCode, description}' /tmp/exec.json

{ "message": "Authorization failed", "httpCode": "401", "description": "token expired" }

Common Root Causes

1. Expired or revoked credential (401)

The stored API key/token is no longer valid — rotated upstream, revoked, or expired — so the target returns 401.

# Reproduce the exact call the node makes, with the same token
curl -s -o /dev/null -w "%{http_code}\n" \
  -H "Authorization: Bearer $TOKEN" https://api.crm.example.com/v1/contacts

401

A bare-curl 401 with the same token confirms the credential, not n8n, is the problem.

2. OAuth2 token failed to refresh

For OAuth2 credentials, n8n auto-refreshes using the refresh token. If the refresh token is revoked or the client secret changed, refresh fails and every call 401s.

jq '.data.resultData.error.description' /tmp/exec.json

"invalid_grant: refresh token expired or revoked"

invalid_grant on refresh means re-authorizing the OAuth2 credential in n8n is required; the access token can’t be renewed.

3. ECONNRESET from idle keep-alive reuse

n8n reuses HTTP keep-alive sockets. If the server (or a proxy/load balancer) closed an idle connection that n8n then reused, the next write gets an RST → ECONNRESET.

# Does the target close idle connections quickly?
curl -sv https://api.crm.example.com/health 2>&1 | grep -iE "keep-alive|timeout|Connection:"

< Connection: keep-alive
< Keep-Alive: timeout=5

A 5s server keep-alive against longer client idle windows produces sporadic resets; enable retry-on-fail for the node.

4. TLS / protocol mismatch resets the connection

A target that requires TLS 1.2+ or rejects the cipher/SNI resets the handshake, surfacing as ECONNRESET rather than a clean HTTP error.

curl -sv https://api.crm.example.com/v1/ping 2>&1 | grep -iE "SSL|TLS|handshake|reset"

* OpenSSL/3.0: error:0A000410:SSL routines::ssl/tls alert handshake failure
* Closing connection

A handshake failure here means the node’s request never completed at the TLS layer.

5. Malformed payload / missing header rejected then reset

Some gateways reset (rather than 400) on an oversized body, missing Content-Type, or an unexpected header. The node fails with a transport error even though it’s a request-shape problem.

# Compare a minimal known-good request vs the node's body size
jq '.data.resultData.runData | keys' /tmp/exec.json
curl -s -o /dev/null -w "%{http_code} %{size_request}\n" \
  -X POST -H 'Content-Type: application/json' \
  -d '{"name":"test"}' https://api.crm.example.com/v1/contacts

201 184

If a minimal request succeeds but the node’s large/odd body resets, fix the node’s body or headers.

6. Node timeout shorter than the target’s response time

A low per-node timeout aborts a slow-but-valid response, which can surface as a reset/abort on the socket.

grep -RniE "N8N_DEFAULT_TIMEOUT|timeout" /etc/n8n/.env 2>/dev/null | head

N8N_DEFAULT_TIMEOUT=10000

A 10s default against an endpoint that takes 15s will abort mid-flight; raise the node/global timeout.

Diagnostic Workflow

Step 1: Read the exact node error

n8n export:execution --id <ID> --output /tmp/exec.json
jq '.data.resultData.error | {message, httpCode, description}' /tmp/exec.json

httpCode: 401 → credential/OAuth path. ECONNRESET/socket hang up → transport path.

Step 2: For 401, reproduce with the same token

curl -s -o /dev/null -w "%{http_code}\n" -H "Authorization: Bearer $TOKEN" <URL>

A 401 confirms the credential. Re-enter the API key or re-authorize the OAuth2 credential in n8n.

Step 3: For OAuth2, check the refresh outcome

jq '.data.resultData.error.description' /tmp/exec.json

invalid_grant → re-connect the OAuth2 credential (refresh token is dead); verify client id/secret match the provider.

Step 4: For ECONNRESET, probe the connection and TLS

curl -sv <URL> 2>&1 | grep -iE "keep-alive|timeout|SSL|TLS|handshake|reset"

Identify a short server keep-alive or a TLS handshake failure; enable the node’s “Retry On Fail” for transient resets.

Step 5: Validate payload, headers, and timeout

grep -RniE "N8N_DEFAULT_TIMEOUT" /etc/n8n/.env
# Re-send a minimal known-good request with curl

Fix body/Content-Type issues and raise the timeout if the endpoint is legitimately slow.

Example Root Cause Analysis

The “Sync Orders -> CRM” workflow starts failing on its CRM node with “Node execution failed”. The error detail:

jq '.data.resultData.error | {message, httpCode, description}' /tmp/exec.json

{ "message": "Authorization failed", "httpCode": "401", "description": "invalid_grant: refresh token expired or revoked" }

This is the OAuth2 path: the node’s access token expired and n8n tried to refresh it, but the refresh returned invalid_grant. Reproducing the refresh confirms the refresh token itself is dead:

curl -s -X POST https://auth.crm.example.com/oauth/token \
  -d grant_type=refresh_token -d "refresh_token=$RT" \
  -d "client_id=$CID" -d "client_secret=$CS" | jq '.error'

"invalid_grant"

The CRM admin rotated the OAuth application’s client secret last night, which silently invalidated every existing refresh token. n8n can’t renew, so every run 401s.

Fix: update the client secret in the n8n credential and re-authorize (re-run the OAuth consent) to mint a fresh refresh token:

# In n8n: open the OAuth2 credential, paste the new client secret, click "Connect/Reconnect"
n8n executions:retry --id 40213 2>/dev/null

The new tokens are issued, the node authenticates, and the retried execution completes.

Prevention Best Practices

• Configure “Retry On Fail” with backoff on HTTP/service nodes so transient ECONNRESET and brief 5xx don’t fail entire runs.
• Monitor credential expiry: track OAuth2 refresh failures and alert before tokens lapse, and coordinate upstream secret rotations with credential updates in n8n.
• Set a per-node or global timeout that exceeds the slowest legitimate endpoint response, rather than relying on a tight default.
• Add an Error Trigger workflow so failed executions notify a channel instead of failing silently.
• Pin a sensible keep-alive / send minimal, well-formed bodies with explicit Content-Type to avoid gateway resets.
• For ad-hoc triage, the free incident assistant can sort a batch of node failures into credential-vs-transport buckets. More in the automation guides.

Quick Command Reference

# List and export failed executions
n8n executions:list --status error | head
n8n export:execution --id <ID> --output /tmp/exec.json
jq '.data.resultData.error | {message, httpCode, description}' /tmp/exec.json

# Reproduce a 401 with the node's token
curl -s -o /dev/null -w "%{http_code}\n" -H "Authorization: Bearer $TOKEN" <URL>

# Test an OAuth2 refresh
curl -s -X POST <TOKEN_URL> -d grant_type=refresh_token \
  -d "refresh_token=$RT" -d "client_id=$CID" -d "client_secret=$CS" | jq '.error'

# Probe connection / TLS for ECONNRESET
curl -sv <URL> 2>&1 | grep -iE "keep-alive|timeout|SSL|TLS|handshake|reset"

# Check the node/global timeout
grep -RniE "N8N_DEFAULT_TIMEOUT|timeout" /etc/n8n/.env

# Retry a fixed execution
n8n executions:retry --id <ID>

Conclusion

An n8n “node execution failed” almost always resolves into one of two paths — a credential 401 or a transport reset. The usual root causes:

1. The stored API key/token is expired or revoked (401).
2. An OAuth2 refresh failed (invalid_grant), often after an upstream secret rotation.
3. ECONNRESET from reusing an idle keep-alive socket the server already closed.
4. A TLS/protocol mismatch resetting the handshake.
5. A malformed payload or missing header that a gateway resets instead of 400ing.
6. A node timeout shorter than the endpoint’s response time.

Read the node’s httpCode first: 401 sends you to credentials/OAuth, ECONNRESET to the transport and TLS layer — and the fix follows directly.