Control Execution Data Saving for High-Volume Workflows

For high-volume n8n workflows, stop saving execution data for successful runs. Set EXECUTIONS_DATA_SAVE_ON_SUCCESS to none globally while keeping error data for debugging, or override the behavior per workflow in its settings. This removes the constant database I/O that thousands of successful executions per day would otherwise create, without losing the failure records you need.

Why disable success data saving for high-volume workflows?

Even with pruning enabled, saving full execution data for every successful run creates significant I/O overhead. For workflows that execute thousands of times per day (e.g., webhook handlers), disable success data saving entirely.

Real-world example: A webhook handler processes 5,000 events/hour. Each execution stores ~50 KB of data. That is 250 MB/hour or 6 GB/day of execution data written to the database, creating constant I/O pressure.

How do you disable success data saving globally?

# Global setting: don't save successful execution data

EXECUTIONS_DATA_SAVE_ON_SUCCESS=none

# Always save errors for debugging

EXECUTIONS_DATA_SAVE_ON_ERROR=all

# Save manual test executions

EXECUTIONS_DATA_SAVE_MANUAL_EXECUTIONS=true

How do you control execution data saving per workflow?

For more granular control, configure per-workflow settings in the workflow settings panel:

Workflow Settings (gear icon) > Settings tab:

  Save Successful Execution Data: Default (uses global) / Yes / No
  Save Failed Execution Data: Default (uses global) / Yes / No
  Save Manual Execution Data: Default (uses global) / Yes / No
  Timeout Workflow After: 120 seconds (prevents runaway executions)
  Error Workflow: [Select your error-handling workflow]

Tip: Hybrid Approach. Set the global default to none for success, then override to Yes on specific workflows that you are actively debugging or that process critical data where you need an audit trail.

Related: Flatten Deeply Nested API Responses · Use Docker Compose with Health Checks for n8n and PostgreSQL