n8n - 💡(How to fix) Fix A scheduled workflow that syncs GoHighLevel (GHL) CRM opportunity data to Google Sheets crashes mid-execution

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Error Message

Describe the problem/error/question When the workflow crashes, no error notification is surfaced — the workflow silently deactivates Is there a way to receive a notification or error log when a workflow is auto-deactivated? What is the error message (if any)? No explicit error message is displayed. The workflow simply stops executing mid-run and the workflow status changes from Active → Inactive automatically. No error entry appears in the execution log for the failed run. error: all

Root Cause

Suspected root cause: The fan-out architecture causes an extremely high number of node executions per run. With ~2,000 opportunities × 19 filter nodes = ~38,000 node executions per triggered run. This appears to exhaust execution memory or exceed internal execution limits, causing the crash and triggering the auto-deactivation safety mechanism.

RAW_BUFFERClick to expand / collapse

Describe the problem/error/question A scheduled workflow that syncs GoHighLevel (GHL) CRM opportunity data to Google Sheets crashes mid-execution and is automatically unpublished by n8n after several runs. The issue is consistent and reproducible.

The workflow:

Triggers daily via Schedule Trigger Fetches all CRM opportunities from the GHL API (paginated, up to 7,000 records) Splits each opportunity into individual items via the Split Out node Runs each item through 19 parallel Filter nodes (per-item fan-out) to categorise by pipeline stage and ad source Counts matched items via 16 Code nodes Writes results to Google Sheets via 14 separate update calls The workflow initially runs successfully for 1–3 executions, then begins crashing partway through, and eventually n8n automatically deactivates/unpublishes the workflow without any manual action from the user.

Suspected root cause: The fan-out architecture causes an extremely high number of node executions per run. With ~2,000 opportunities × 19 filter nodes = ~38,000 node executions per triggered run. This appears to exhaust execution memory or exceed internal execution limits, causing the crash and triggering the auto-deactivation safety mechanism.

Secondary issues observed:

When the workflow crashes, no error notification is surfaced — the workflow silently deactivates saveDataSuccessExecution: "none" was set, making post-crash debugging impossible The workflow becomes unpublished with no log entry explaining why Questions:

Is there a per-execution node execution limit or memory cap that triggers auto-unpublishing? Is there a way to receive a notification or error log when a workflow is auto-deactivated? What is the recommended pattern for high fan-out workflows (filter → count per item) to avoid hitting these limits? What is the error message (if any)? No explicit error message is displayed. The workflow simply stops executing mid-run and the workflow status changes from Active → Inactive automatically. No error entry appears in the execution log for the failed run.

Please share your workflow/screenshots/recording Below is a simplified version of the crashing workflow structure (credentials and sensitive IDs removed):

{ "name": "Legal Reps- GHL Opportunities (Crash Report)", "nodes": [ { "parameters": { "rule": { "interval": [{ "triggerAtHour": 15, "triggerAtMinute": 45 }] } }, "name": "Daily Trigger", "type": "n8n-nodes-base.scheduleTrigger", "typeVersion": 1.3, "position": [640, 640], "id": "node-trigger" }, { "parameters": { "url": "https://services.leadconnectorhq.com/opportunities/search", "authentication": "genericCredentialType", "genericAuthType": "httpBearerAuth", "sendQuery": true, "queryParameters": { "parameters": [ { "name": "location_id", "value": "REDACTED" }, { "name": "limit", "value": "100" } ] }, "options": { "pagination": { "pagination": { "parameters": { "parameters": [ { "name": "startAfterId", "value": "={{ $response.body.meta.startAfterId }}" }, { "name": "startAfter", "value": "={{ $response.body.meta.startAfter }}" } ] }, "paginationCompleteWhen": "other", "completeExpression": "={{ $response.body.meta.nextPage === null }}", "limitPagesFetched": true, "maxRequests": 20 } } }, "alwaysOutputData": true, "retryOnFail": true, "maxTries": 5 }, "name": "Search All Opportunities", "type": "n8n-nodes-base.httpRequest", "typeVersion": 4.4, "position": [880, 640], "id": "node-http" }, { "parameters": { "fieldToSplitOut": "opportunities", "include": "allOtherFields", "options": {} }, "name": "Split Out1", "type": "n8n-nodes-base.splitOut", "typeVersion": 1, "position": [1120, 640], "id": "node-split" }, { "parameters": { "conditions": { "conditions": [{ "leftValue": "={{ $('Split Out1').item.json.opportunities.createdAt }}", "rightValue": "2026-04", "operator": { "type": "string", "operation": "contains" } }] } }, "name": "Filter by Month", "type": "n8n-nodes-base.filter", "typeVersion": 2.3, "position": [1360, 640], "id": "node-filter-month" }, { "parameters": { "conditions": { "conditions": [{ "leftValue": "={{ $('Split Out1').item.json.opportunities.pipelineStageId }}", "rightValue": "45063b8c-0791-4d00-b185-49b2cf21555d", "operator": { "type": "string", "operation": "equals" } }] } }, "name": "Filter Stage: Docusign", "type": "n8n-nodes-base.filter", "typeVersion": 2.3, "position": [1600, 480], "id": "node-filter-stage-1" }, { "parameters": { "conditions": { "conditions": [{ "leftValue": "={{ $('Split Out1').item.json.opportunities.source }}", "rightValue": "Meta (16 State)", "operator": { "type": "string", "operation": "equals" } }] } }, "name": "Filter Source: Meta 16 State", "type": "n8n-nodes-base.filter", "typeVersion": 2.3, "position": [1840, 400], "id": "node-filter-source-1" }, { "parameters": { "jsCode": "return [{ json: { meta16StateCount: items.length } }];" }, "name": "Count items - 16state", "type": "n8n-nodes-base.code", "typeVersion": 2, "position": [2080, 400], "id": "node-count-1" }, { "parameters": { "operation": "update", "documentId": { "__rl": true, "value": "REDACTED", "mode": "list" }, "sheetName": { "__rl": true, "value": 1472276924, "mode": "list" }, "columns": { "mappingMode": "defineBelow", "value": { "Months": "={{ $('April').item.json.Month }}", "Docusign - Meta (16 State)": "={{ $json.meta16StateCount }}" }, "matchingColumns": ["Months"] } }, "name": "Update Sheet", "type": "n8n-nodes-base.googleSheets", "typeVersion": 4.7, "position": [2320, 400], "id": "node-sheet-1" } ], "notes": "NOTE: The full workflow contains 55 nodes total — this is a representative excerpt showing the repeating pattern. The full fan-out is: 1 Split Out → 1 Month Filter → 4 Stage Filters → (3–4 Source Filters each) → 16 Count nodes → 14 Google Sheets update nodes. All Filter and Count nodes run once per item (per opportunity), resulting in ~38,000 node executions per run with 2,000 opportunities.", "settings": { "executionOrder": "v1", "timezone": "America/Los_Angeles", "saveDataSuccessExecution": "none", "saveManualExecutions": false } } Workflow structure summary:

Schedule Trigger └─► HTTP Request (paginated, up to 2000 opportunities) └─► Split Out (1 item per opportunity → ~2000 items) └─► Filter: Month ← runs 2000× ├─► Filter: Stage 1 (Docusign) ← runs 2000× │ ├─► Filter: Source A → Count → Sheet Update │ ├─► Filter: Source B → Count → Sheet Update │ └─► Filter: Source C → Count → Sheet Update ├─► Filter: Stage 2 (Signed Doc) ← runs 2000× ├─► Filter: Stage 3 (Clio) ← runs 2000× └─► Filter: Stage 4 (Disengagement) ← runs 2000× Total node executions per run ≈ 2000 items × 19 filter nodes = ~38,000 Share the output returned by the last node No output is available — saveDataSuccessExecution was set to "none" and the execution log for crashed runs contains no data. The workflow simply stops and deactivates silently.

Debug info core n8nVersion: 2.13.3 platform: (cloud) nodeJsVersion: 24.13.1 nodeEnv: production database: sqlite executionMode: regular concurrency: 5 license: enterprise (sandbox) storage success: all error: all progress: false manual: true binaryMode: filesystem pruning enabled: true maxAge: 168 hours maxCount: 2500 executions client userAgent: mozilla/5.0 (macintosh; intel mac os x 10_15_7) applewebkit/537.36 (khtml, like gecko) chrome/147.0.0.0 safari/537.36 isTouchDevice: false Generated at: 2026-04-20T18:25:25.688Z

extent analysis

TL;DR

The workflow is likely crashing due to excessive node executions, causing it to exceed internal execution limits, and can be fixed by optimizing the workflow structure to reduce the number of node executions.

Guidance

  • Review the workflow structure to identify opportunities for optimization, such as combining filter conditions or reducing the number of parallel filter nodes.
  • Consider implementing a batching mechanism to process opportunities in smaller chunks, reducing the overall number of node executions.
  • Investigate the concurrency setting in the n8n configuration, as a high concurrency value may exacerbate the issue.
  • Enable saveDataSuccessExecution to retain execution data, allowing for better debugging and error analysis.

Example

No code snippet is provided, as the issue is related to workflow structure and configuration rather than code.

Notes

The exact error message or log entry is not available due to the saveDataSuccessExecution setting being set to "none". Enabling this setting may provide more insight into the issue.

Recommendation

Apply a workaround by optimizing the workflow structure to reduce node executions, as the root cause is likely related to excessive executions exceeding internal limits.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING