Vos workflows n8n tournent depuis des mois. Un jour, l'instance ralentit, ou le disque du serveur est plein, et personne ne comprend pourquoi : aucun workflow n'a changé. Le coupable est souvent le plus discret : l'historique des exécutions, que n8n enregistre à chaque passage.
Cet article explique ce que n8n conserve, comment fonctionne la purge automatique, et quels réglages poser pour qu'un historique utile ne devienne pas un problème. Les faits sur n8n viennent de sa documentation officielle, citée en fin d'article ; les recommandations sont notre analyse, à adapter à votre contexte.
Pourquoi l'historique grossit
Chaque exécution d'un workflow produit une trace : les données qui ont traversé chaque nœud, l'état final, et parfois des fichiers. Cette trace sert à comprendre un incident, relancer un traitement ou vérifier ce qui s'est passé. Mais elle s'accumule. La documentation de n8n le dit clairement : les données d'exécution peuvent faire grossir la base jusqu'à épuiser l'espace de stockage, et elle recommande de ne pas enregistrer les données inutiles et d'activer la purge des anciennes exécutions.
Plus un workflow est fréquent et manipule de données volumineuses (listes de contacts, pièces jointes, réponses d'API), plus l'historique pèse vite. Une automatisation qui s'exécute toutes les minutes en produit plus de 40 000 par mois.
Ce que n8n purge par défaut
n8n sait supprimer automatiquement les exécutions terminées, avec leurs données. D'après la documentation, cette purge est activée par défaut. Elle se déclenche selon deux conditions, la première atteinte suffisant :
| Réglage | Rôle | Valeur par défaut indiquée |
|---|---|---|
EXECUTIONS_DATA_PRUNE |
Active la suppression des anciennes exécutions | true |
EXECUTIONS_DATA_MAX_AGE |
Âge, en heures, au-delà duquel une exécution est supprimée | 336 (14 jours) |
EXECUTIONS_DATA_PRUNE_MAX_COUNT |
Nombre maximal d'exécutions conservées (0 : pas de limite) |
10000 |
Quelques précisions utiles, tirées de la même documentation :
- La suppression se fait en deux temps : n8n marque d'abord les exécutions à supprimer, puis les supprime définitivement un peu plus tard.
- Les exécutions en cours, en attente ou nouvelles ne sont pas concernées.
- Les exécutions annotées (par exemple avec une étiquette ou une évaluation) ne sont jamais purgées.
- Quand le plafond de nombre est dépassé, les plus anciennes sont supprimées d'abord, et le total peut ne pas retomber exactement au maximum.
Autrement dit, avec les valeurs par défaut, une instance conserve au plus 14 jours d'historique et 10 000 exécutions. C'est suffisant pour beaucoup de PME, et insuffisant pour d'autres.
Estimer sa rétention réelle
Les deux limites se combinent, et c'est souvent la seconde qui joue. Un calcul simple suffit pour savoir ce qui vous concerne. Prenons un exemple illustratif, avec les valeurs par défaut :
- Un workflow lancé toutes les 5 minutes produit 288 exécutions par jour, soit environ 4 000 sur 14 jours : le plafond de 10 000 n'est pas atteint, c'est l'âge qui décide.
- Un workflow lancé toutes les minutes produit 1 440 exécutions par jour, soit plus de 20 000 sur 14 jours : le plafond de 10 000 est atteint en moins de 7 jours, et c'est lui qui décide. L'historique réellement disponible est alors d'environ une semaine, et non de quatorze jours.
- Plusieurs workflows s'additionnent : le plafond vaut pour l'ensemble de l'instance, pas pour chaque workflow. Un seul workflow très bavard peut donc repousser dehors l'historique de tous les autres.
Ce dernier point est la surprise la plus fréquente : on cherche l'exécution d'un workflow rare, lancée il y a trois jours, et elle a déjà disparu parce qu'un autre workflow a rempli le quota.
Choisir ce qu'on enregistre
La purge limite la durée de vie des données. Le second levier est de ne pas les enregistrer du tout. La documentation décrit des réglages d'instance, que l'on peut aussi ajuster workflow par workflow dans les paramètres du workflow :
EXECUTIONS_DATA_SAVE_ON_ERROR: enregistrer ou non les exécutions en échec (allounone) ;EXECUTIONS_DATA_SAVE_ON_SUCCESS: enregistrer ou non les exécutions réussies (allounone) ;EXECUTIONS_DATA_SAVE_MANUAL_EXECUTIONS: enregistrer ou non les exécutions lancées à la main ;EXECUTIONS_DATA_SAVE_ON_PROGRESS: enregistrer la progression de chaque nœud pendant l'exécution (désactivé par défaut d'après la table de référence des variables).
Le choix le plus courant est de conserver les échecs et de ne pas conserver les succès sur les workflows très fréquents. L'historique reste alors utile (on voit ce qui a cassé) sans stocker des milliers de passages qui ont fonctionné.
Un historique trop court a aussi un coût
Réduire la rétention soulage la base, mais retire des preuves. Avant de raccourcir, posez trois questions :
- Combien de temps faut-il pour détecter un problème ? Si une erreur n'est repérée qu'une semaine plus tard, un historique de 48 heures ne servira à rien. Une alerte à l'échec raccourcit ce délai : voir notre article sur la gestion des erreurs avec l'Error Trigger.
- Faut-il rejouer des traitements ? Relancer une exécution suppose que ses données existent encore.
- Y a-t-il une obligation de conservation ou, à l'inverse, de minimisation ? Les données d'exécution contiennent souvent des informations de clients ou de prospects. Pour le cadre RGPD, voyez notre article n8n Cloud ou auto-hébergé : que change le RGPD en PME ?. La durée de conservation doit être décidée, pas subie.
Cas particulier : SQLite
Les petites installations utilisent souvent SQLite comme base. La documentation prévient que l'espace libéré par la purge n'est pas rendu au système : il est réutilisé pour les futures données d'exécution. Le fichier ne diminue donc pas tout seul. Pour récupérer l'espace, elle indique d'activer DB_SQLITE_VACUUM_ON_STARTUP ou de lancer une commande VACUUM manuellement. Faites une sauvegarde avant toute opération sur la base : notre article sur la sauvegarde et le versionnement des workflows détaille ce qu'il faut protéger.
Où poser ces réglages
Ces variables relèvent de la configuration de l'instance : elles se définissent dans l'environnement du serveur ou du conteneur qui fait tourner n8n. Si votre instance est hébergée chez n8n (Cloud), vérifiez dans la documentation de votre formule ce qui est modifiable avant de compter sur ces variables. Les réglages par workflow, eux, passent par l'interface.
Une configuration de départ pour une PME
Ces règles sont notre recommandation de départ, à ajuster :
- Laisser la purge activée. C'est la valeur par défaut documentée ; ne la désactivez que pour une raison précise.
- Choisir une durée assumée. Si 14 jours conviennent, gardez la valeur par défaut. Sinon, fixez
EXECUTIONS_DATA_MAX_AGEexplicitement et notez pourquoi. - Ne pas enregistrer les succès des workflows très fréquents, mais conserver les échecs.
- Annoter les exécutions à garder (litige, preuve, cas de test) : les exécutions annotées ne sont pas purgées.
- Surveiller l'espace disque et alerter avant qu'il soit plein.
- Revoir ce réglage quand le volume change. Un workflow qui passe de 100 à 10 000 passages par jour change l'équation.
Les erreurs fréquentes
- Désactiver la purge « pour être tranquille » : la base finit par saturer le disque.
- Tout supprimer pour gagner de la place : le jour d'un incident, il ne reste rien pour comprendre.
- Oublier les données personnelles que contiennent les exécutions.
- Attendre que le fichier SQLite diminue après une purge sans avoir libéré l'espace.
Besoin d'un cadre pour vos automatisations ?
Votre instance n8n grossit sans que personne ne sache quoi garder ? Décrivez-nous votre situation : nous vérifions votre configuration, fixons une rétention cohérente avec vos obligations et mettons en place la surveillance. Nos offres détaillent les formats d'accompagnement, et vous pouvez nous contacter directement.
Sources
- n8n, Execution data, documentation consultée le 19 octobre 2026.
- n8n, Executions environment variables, documentation consultée le 19 octobre 2026.