Control Execution 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.

# 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
```text
For more granular control, configure per-workflow settings in the workflow settings panel:

```text
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]
```text
> **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](../code-node-mastery/01-flatten-deeply-nested-api-responses.md) | [Use Docker Compose with Health Checks for n8n and PostgreSQL](../self-hosting-operations/01-use-docker-compose-with-health-checks-for-n8n-and-postgresql.md)