How to troubleshoot n8n workflow failures

Executions tab → click any red row → the editor opens with the failing node highlighted.

Click the red node. The output panel shows: error type, error message, stack trace (if applicable), and HTTP status (for API nodes).

Common error patterns:

- '401 Unauthorized' / 'Invalid credentials' → credential expired or rotated. Re-auth.

- '429 Too Many Requests' → rate limited. Add Wait node or split into batches.

- 'Cannot read property X of undefined' → expression references a field that does not exist on this record.

- 'No data returned' → trigger output empty; check the source app.

Resist the urge to immediately fix without reading. The error message tells you exactly what is wrong 80% of the time.

Executions tab → filter by Status = Error. Sort by date descending.

If you see 1 error in the last 100 runs: probably a transient issue (API blip, timed-out request). Add retry-on-fail to the node and move on.

If you see errors clustered in the last 24 hours: something changed recently. Check: did you edit the workflow? Did the source app push a schema change? Did a credential expire?

If errors are constant since day 1: the workflow was never working right. Walk through the build step by step.

If errors are intermittent across weeks: rate limits, conditional data shapes, or upstream flakiness. Add retries + better field-existence checks.

In the failing execution, note which credentials the failing node uses (visible in the node config).

Go to Settings → Credentials. Click the relevant credential.

For OAuth credentials: look for an "Expired" or "Token needs refresh" indicator. Re-authorize from the credential settings.

For API key credentials: check the vendor portal — was the key rotated, deleted, or scoped down? Update the credential value if so.

Test the credential with the credential's built-in test button. Most credentials have a "Test connection" feature; use it.

Open the workflow. Click the trigger node. Click "Execute Step" or "Listen for Test Event" to pull fresh sample data.

Compare the new sample to what your downstream nodes expect. Are field names different? Is a previously-required field now optional (or vice versa)?

Common cause: vendor API updates (Shopify, HubSpot, Stripe). New fields added, deprecated fields removed.

Fix: re-map field references in downstream nodes. Use `??` fallbacks for fields that may not exist: `{{ $json.customField ?? "default" }}`.

Set a calendar reminder to re-pull sample data quarterly for production workflows. Schema drift is the #2 cause of slow-burn breakage after credential expiry.

Right-click the trigger node → "Pin Data." n8n caches the current sample.

Now you can re-execute the workflow against the pinned data repeatedly without re-pulling from the source.

Useful when the source is slow (rate-limited) or non-deterministic (varying data).

Also useful for the inverse: pin known-good data, then deliberately break it (delete a field) to verify your fallback logic works.

Remember to unpin before activating. Otherwise the workflow runs against stale sample data forever.

Look at the failing execution. Was it processing many records?

If yes and the error is "429 Too Many Requests" or similar: the destination app is rate-limiting.

Fix 1: add a "Wait" node between the loop and the action, set to 1-5 seconds.

Fix 2: use "Split In Batches" earlier — process 50 at a time instead of 500.

Fix 3: check the destination app for batch endpoints. HubSpot, Mailchimp, and others support batch operations that count as one API call.

For pagination: if the trigger node has a "Limit" field, it caps how many records it pulls per execution. Increase it OR set up a scheduled trigger that handles the next batch.

Sometimes the workflow does not fail — it succeeds while producing wrong data. The culprit is often "Continue on Fail" on a critical node.

Click each node in the failing workflow → Settings → look for "Continue on Fail" toggle.

For nodes where partial failure is acceptable (e.g., enrichment lookups that may or may not find a match), Continue on Fail is right.

For nodes where failure should halt the workflow (e.g., the primary write to your CRM), Continue on Fail should be OFF. Otherwise downstream nodes run with null inputs.