n8n Execution Retention: A Preflight Checklist Before Changing What You Save

Before changing execution retention, decide what evidence you need to investigate a problem and who can access it. Saving fewer records and deleting older saved records are separate choices. This checklist concerns self-hosting; confirm Cloud settings and plan limits separately.

Inventory the current configuration

Record your n8n version, database, binary-data mode, setting overrides, execution volume and which outcomes are saved. Identify who investigates failures and how long they need to do so. Avoid copying sensitive payloads into a second ledger merely to keep them indefinitely.

The current self-hosted guide documents pruning enabled by default, with age 336 hours and count 10,000. These are documented defaults, not verified values for your installation. Read the active configuration before changing it.

Make the evidence requirement explicit

Requirement	Record the decision
Investigation window	Required days and business reason
Saved outcomes	Success, failure, manual runs and other needed evidence
Minimum evidence	Identifiers and outcomes needed to reconcile a problem
Access	Who may view execution content and credentials-related information
Recovery	What authorised backup or alternative evidence exists

If a team needs four days to investigate an issue, treat that as a requirement to check against volume and retention, not a setting that this article recommends universally. Debugging from past executions also depends on saved data and feature availability for the edition.

Compare age and count limits

In an invented example, 3,000 executions per day reach a 10,000-record cap in roughly 3.3 days. A 14-day age limit does not guarantee 14 days of accessible history when a count condition is reached earlier. This calculation is illustrative, not an observation of a deployed instance.

Separate pruning from reclaimed storage

The guide excludes new, running, waiting and annotated executions from pruning, and describes staged deletion. Deleted SQLite space can be reused without the file automatically shrinking. Binary pruning acts on the currently active storage mode; changing modes does not establish that old storage is removed.

Visible execution counts, completed deletion and reclaimed disk space are different observations. Backups can also retain information after it disappears from the live view. Check each relevant storage location rather than inferring deletion from a shorter list.

Verify a small authorised change

Plan a test with dummy executions in an authorised non-production environment. Confirm which records remain available for investigation, whether expected exceptions remain, and what happened to the database and binary storage. Keep a recovery plan before any deletion.

Reverting settings cannot restore records already deleted. This article does not report a completed retention test or prescribe a destructive cleanup command for an unseen installation.