Execution History Retention by n8n Plan: 7 Days to Unlimited

n8n stores the history of past workflow executions for different lengths of time depending on the pricing plan. According to the official pricing page n8n.io/pricing it is 7 days on the Starter plan, 30 days on the Pro plan, and unlimited on the Enterprise plan. For a self-hosted Community Edition, the software sets 14 days by default, which you can freely adjust via an environment variable of your installation. These periods determine how long you can still view failed or successful executions afterward and use them for debugging or record-keeping purposes. As of: July 2026.

Retention periods by plan at a glance

The following list summarizes what n8n currently states for the individual plans. Important: besides the plain day limit, some plans also cap the number of stored executions and the storage space used, whichever limit is reached first.

• Community (Self-Hosted): no fixed value on the pricing page; the default in the software is 336 hours, i.e. 14 days, freely configurable via the environment variable EXECUTIONS_DATA_MAX_AGE
• Starter: 7 days, additionally limited to a maximum of 2,500 stored executions and 2.5 GB of storage space
• Pro: 30 days, additionally limited to a maximum of 25,000 stored executions and 25 GB of storage space
• Business: not listed separately as its own value in the official comparison table; the plan card names all Pro features plus 30 days of insights history, a separate analytics feature that is not the same as execution log retention
• Enterprise: unlimited, additionally listed on the pricing page as its own feature "Extended data retention"

Relevance for debugging

The longer the execution history reaches back, the better errors can be reconstructed afterward. If a workflow runs only once a week and then fails, the 7 days of retention on the Starter plan is often not enough to still view the exact input and output data of each individual node. Especially with sporadic errors, for example caused by an unstable external API or unexpected data formats, looking at the exact values of a past execution is often the only way to find the cause. For workflows with an irregular rhythm, it is therefore worth looking at the combination of the day limit and the additional limits on quantity and storage space, since a very active workflow can reach the quantity limit before the day limit and lose older runs.

Relevance for compliance and record-keeping obligations

For workflows related to accounting, such as automated invoice verification, DATEV exports, or payment reconciliation, a long execution history may at first seem like a convenient proof that a process ran correctly. Honesty matters here: n8n's execution history is a debugging tool, not a legally vetted archive. Statutory retention obligations for accounting records in Germany require significantly longer periods than even the Enterprise plan technically provides with "unlimited", and the requirements for a GoBD-compliant, immutable storage are not automatically met by a workflow history in the editor. Anyone using n8n for accounting-relevant processes should additionally write receipts and result data to their own audit-proof storage system instead of relying solely on the retention period included in the plan. NordFlux helps with choosing the right plan and setting up such an additional, audit-proof storage as part of its n8n consulting.

Frequently asked questions about n8n execution history retention

How long do executions remain visible on the n8n Starter plan?

7 days, additionally limited to a maximum of 2,500 stored executions and 2.5 GB of storage space. As soon as one of these limits is reached, n8n removes the oldest entries first.

Can I set the retention period myself on a self-hosted installation?

Yes. On the Community Edition, you determine the period via the environment variable EXECUTIONS_DATA_MAX_AGE of your own installation; the default value is 336 hours, i.e. 14 days, according to the n8n documentation.

Does the execution history replace a statutory retention obligation?

No. Execution logs are meant for debugging, not for GoBD-compliant archiving. For accounting-relevant records, you should additionally store receipts and result data in your own permanently maintained system.

What happens if I exceed the limit of stored executions?

n8n automatically removes the oldest entries as soon as one of the limits, i.e. day limit, quantity, or storage space, is reached. Running and future workflows are not stopped as a result, only the viewable history becomes shorter.