Your n8n instance just crashed. The culprit? A bloated database stuffed with months of execution logs nobody configured properly.
This guide walks you through everything about data retention policies for n8n execution logs, from default pruning rules to advanced environment variables that keep your workflows running smoothly.
Managing execution logs in n8n requires a VPS that can handle storage efficiently over time. The comparison table below highlights VPS hosting providers that offer stable disk performance and scalable storage options for log retention. These environments help ensure your logs remain accessible without impacting system performance. Explore our recommended VPS hosting options.
VPS Hosting Providers With Reliable Storage and Log Management Support
| Provider | User Rating | Recommended For | |
|---|---|---|---|
 | 4.8 | Scalability | Visit Kamatera |
 | 4.6 | Affordability | Visit Hostinger |
 | 4.7 | Developers | Visit IONOS |
Understanding How n8n Stores Execution Data
The Core Architecture of n8n Storage
Unlike platforms that keep data exclusively in memory, n8n stores workflow execution data in a persistent database. This architecture ensures historical analysis and debugging capabilities remain available long after a workflow has finished running.
Administrators can choose between n8n’s fully managed cloud offering, which handles database optimization automatically, or flexible self-hosted deployments. The self-hosted method offers granular control via hosting configurations through quality n8n hosting providers.
Properly managing this storage prevents database exhaustion. Without careful configuration, you risk instance crashes or out-of-memory errors that bring everything to a halt.
What Gets Captured in Execution Logs
Every time a workflow runs, n8n captures detailed information across several categories.
Node-level data includes input and output for every step of the process. The system also stores contextual information like parameters, variables, and the overall execution context. Media references maintain links to binary data processed during the run, including images, documents, audio files, and videos.
This comprehensive logging makes debugging easier. But it also means your database grows quickly with each finished execution.
Default Execution Data Retention and Pruning Mechanisms
1. The 14-Day or 10,000 Execution Rule
By default, n8n enables automatic pruning through the EXECUTIONS_DATA_PRUNE=true configuration. This protects system stability without requiring manual intervention.
The system retains executions for either 336 hours (14 days) or the last 10,000 executions. Whichever limit hits first triggers cleanup. High-frequency workflow runs can exhaust the count threshold well before the time limit, making manual configuration vital for heavy users dealing with significant execution volume.
2. Soft-Deletion vs. Hard-Deletion Phases
Pruning operates on a rolling basis through a safe two-phase process. Soft deletion occurs every 60 minutes by default, marking older executions for removal. Hard deletion runs every 15 minutes, permanently removing soft-deleted data from the database.
A built-in one-hour safety buffer protects recent runs from premature hard deletion. This prevents accidental data loss while users are actively debugging failures or reviewing recent executions.
Ultahost
3. Executions Exempt from Automatic Pruning
Not all data faces the automatic pruning block. N8n intelligently protects active and important workflows.
Executions with a status of “new,” “running,” or “waiting” are completely exempt from age-based pruning. Any execution that a user has manually annotated executions with tags or ratings receives permanent protection. This ensures vital compliance records never get automatically deleted.
Cloud-Based Execution Data Retention Limits and Tiers
Pricing and Retention Specifications
N8n’s cloud offering implements strict tier-based retention policies that scale with your subscription. Starter plans work for basic testing, while Enterprise options offer unlimited historical records capped by execution count.
| Plan Tier | Monthly Cost (Annual) | Maximum Executions Saved | Log Retention | Concurrent Executions | RAM per Execution |
|---|---|---|---|---|---|
| Starter | €20 | 2,500 | 7 days | 5 | 320 MiB |
| Pro | €50 | 25,000 | 30 days | 20 | 1,000 MiB |
| Business | €667 | 50,000 | Unlimited | 200+ | Higher |
| Enterprise | Custom | 50,000 | Unlimited | 365+ | Custom |
Automatic Pruning at 85% Disk Capacity
N8n Cloud actively monitors server disk capacity to guarantee instance stability. When your cloud instance reaches 85% of allocated disk usage, an automated alert system triggers.
The platform performs an emergency backup of workflows, users, and credentials. Then it restores your instance without execution data. This results in a complete wipe of execution history regardless of your plan’s retention settings. Understanding this helps you avoid unpleasant surprises.
Configuring Environment Variables for Self-Hosted Deployments
1. Setting Maximum Age and Count Limits
Self-hosted environments give you ultimate control over retention limits. You can set environment variables to customize behavior precisely.
EXECUTIONS_DATA_MAX_AGE defines age-based retention in hours. The default is 336 hours. Setting this to 720 retains data for 30 days instead.
EXECUTIONS_DATA_PRUNE_MAX_COUNT controls the maximum number of total stored executions. The default sits at 10,000 records.
2. Adjusting the Hard-Delete Safety Buffer
EXECUTIONS_DATA_HARD_DELETE_BUFFER controls the safety window before permanent deletion. The default allows one hour for debugging.
Increasing this buffer gives developers longer to review recently finished workflows before pruned data disappears. You can also modify EXECUTIONS_DATA_PRUNE_SOFT_DELETE_INTERVAL and EXECUTIONS_DATA_PRUNE_HARD_DELETE_INTERVAL to change how frequently the database runs cleanup scripts.
Selective Data Capture to Reduce Storage Overhead
1. Optimizing for Successful vs. Failed Runs
Capturing every workflow outcome drains database storage quickly. Smart configuration focuses on what matters.
EXECUTIONS_DATA_SAVE_ON_SUCCESS can be set to “none” so the system ignores successful production runs. EXECUTIONS_DATA_SAVE_ON_ERROR should be set to “all” to capture only failed runs. This preserves complete context for troubleshooting while minimizing storage overhead.
2. Disabling Progress and Manual Execution Tracking
EXECUTIONS_DATA_SAVE_ON_PROGRESS defaults to “false.” Setting it to “true” captures intermediate node steps but drastically increases memory pressure.
EXECUTIONS_DATA_SAVE_MANUAL_EXECUTIONS defaults to “true.” Setting this to “false” stops n8n from saving test executions triggered manually from the editor. This keeps your database clean of development clutter and small workloads that don’t need permanent records.
Where n8n Stores Binary Data and Media
Memory vs. Filesystem vs. Database Storage Modes
Binary data is the most storage-intensive component of execution logs. Understanding your options helps you make smart choices.
Memory mode holds binary data in RAM during execution. This works for simple workflows but can cause out-of-memory crashes when processing hundreds of large files.
Filesystem mode streams data directly to disk. Configure it via N8N_DEFAULT_BINARY_DATA_MODE=filesystem. This vastly reduces RAM consumption for single-worker deployments.
Database mode works best for queue mode deployments. It allows multiple workers to safely share binary data references. You can also consider external storage solutions for very large implementations.
Binary Data Pruning Behaviors
When an execution gets pruned via age or count limits, associated binary data also gets deleted. Pruning only operates on the currently active storage mode.
Here’s the catch: if you switch from S3 to filesystem storage, n8n only prunes filesystem data. Legacy S3 data requires manual cleanup. Check the official documentation for detailed export and migration procedures.
Overcoming Common Configuration Challenges
1. The “Zero Limit” Pruning Issue
Setting EXECUTIONS_DATA_PRUNE_MAX_COUNT=0 should disable count-based pruning entirely. However, users have reported unexpected aggressive pruning with certain database types when using this approach.
Instead of zero, set the count limit to an exceptionally high number like 50,000 or 100,000. This safely bypasses early count-based deletion without triggering bugs. Always run the latest stable version to minimize such issues.
2. Managing the Execution Entity and Separate Table Data
SQLite deployments handle space differently. Pruning marks space as reusable but doesn’t shrink file size. Configure DB_SQLITE_VACUUM_ON_STARTUP or run manual VACUUM commands to reclaim space.
PostgreSQL requires similar maintenance. Running VACUUM FULL on the execution_data table physically shrinks the database. One example reduced a database from 800 MB to 250 MB using this method.
Programmatic Cleanup and Custom Workflow Overrides
Building Workflows for Custom Deletion Logic
Administrators can create custom workflows that programmatically delete old executions using n8n’s native API nodes. The API allows retrieving up to 250 recent executions per call.
Bulk deletion of large datasets can trigger API rate limits. Attempting to delete 5,000+ executions at once often results in error code 524 responses. Careful batch size management through your workflow settings prevents these failures.
Setting Per-Workflow Retention Rules
Global environment variables can be overridden at the individual workflow level through the options menu. High-frequency utility workflows can save successful executions differently than critical business processes.
This granular control prevents a single noisy workflow from dominating the database and forcing expensive infrastructure upgrades. You can even configure a sub workflow differently from its parent.
Establishing a Production-Ready Retention Policy
1. Documenting Compliance Requirements
Before adjusting settings, define how long logs must be kept. Financial and healthcare organizations may require years of retention to satisfy regulatory audits.
Check our guide on hosting n8n in regulated industries for GDPR and HIPAA considerations.
Standard business processes typically only need 30 to 90 days of execution history. Your account requirements determine the right approach.
2. Calculating Execution Volume for Peak Demand
Count limits must align with actual volume. If a workflow runs 100 times daily, the default 10,000 limit only provides 100 days of history.
To achieve one-year retention at that frequency, set EXECUTIONS_DATA_PRUNE_MAX_COUNT=36500. Match your settings to real usage patterns.
3. Monitoring Storage and Alert Systems
Cloud deployments on Pro and Enterprise plans feature “Insights” for visibility into execution trends over 7 to 365 days. Set alerts when you hit 90% of your tier limit.
Self-hosted administrators can query the execution_entity table to verify oldest and newest timestamps. The /metrics endpoint exposes Prometheus-compatible data for integration with Grafana monitoring stacks. Consider this a best practice for any production deployment.
The Cost Implications of Your Retention Policy
Cloud Tier Upgrades vs. Self-Hosted Infrastructure
Cloud costs escalate with usage. Exceeding execution counts forces tier upgrades. Running 50,000 executions monthly requires the €50 Pro plan. More than 100,000 needs custom Enterprise pricing.
Self-hosted total cost of ownership typically ranges from $300 to $800 monthly. This includes premium server storage, maintenance, security, and staff time.
Organizations must weigh these factors when planning long-term execution data retention. Our n8n self-hosted vs cloud comparison breaks down these trade-offs in detail. For budget-conscious teams, affordable n8n hosting options exist that balance cost with performance.
Setting Up Your Infrastructure Right
Whether you choose cloud or self-hosted, proper infrastructure matters. If you’re building automation workflows that handle sensitive data or require reliable uptime, consider investing in quality hosting.
A solid VPS solution gives you the control needed for custom retention configurations. You maintain full ownership over credentials, database maintenance, and backup schedules. This foundation supports everything from simple triggers to complex multi-node automation projects.
For deeper technical guidance on keeping your database healthy after enable pruning operations, our n8n database optimization guide covers essential maintenance practices.
Conclusion
Managing data retention policies for n8n execution logs requires balancing storage costs against debugging needs. Default settings work for many users, but serious production deployments need custom configuration.
Whether you prune daily or keep months of history depends on your compliance requirements and workflow volume. Start with the defaults, monitor your disk space, and adjust settings as your automation scales.
Next Steps: What Now?
- Review your current execution count and storage usage in n8n settings.
- Document your compliance requirements for log retention.
- Configure environment variables matching your actual workflow volume.
- Set up monitoring alerts at 80% capacity thresholds.
- Schedule regular database maintenance for SQLite or PostgreSQL.
- Test your backup and restore process before you need it.
