Décrivez le problème/l’erreur/la question
Crash du workflow de l'instance cloud de n8n.
Mon workflow fonctionnait correctement depuis les 3 derniers mois, mais hier, sans raison apparente, il a échoué 3 fois et n8n l’a automatiquement désactivé. Il y a eu des incidents où le système a échoué plus de 30 fois sans jamais s’arrêter. Celui-ci s’est arrêté après seulement 3 échecs. De plus, j’ai réessayé 3 fois sur les nœuds où il a échoué, mais il s’est quand même écrasé en raison d’un manque d’espace mémoire. Dans la documentation, il est dit que n8n redémarrera automatiquement l’instance, mais cela ne s’est pas produit non plus - j’ai dû la redémarrer manuellement après une journée aujourd’hui. Quelles précautions puis-je prendre pour l’avenir ?
Quel est le message d’erreur (le cas échéant) ?
Exécution arrêtée à ce nœud
n8n a peut-être manqué de mémoire lors de l’exécution. Plus de contexte et de conseils sur comment éviter cela dans la documentation
Veuillez partager votre workflow
(Sélectionnez les nœuds sur votre canevas et utilisez les raccourcis clavier CMD+C/CTRL+C et CMD+V/CTRL+V pour copier et coller le workflow.)
Partagez la sortie renvoyée par le dernier nœud
Informations sur votre configuration n8n
- Version de n8n :
- Base de données (par défaut : SQLite) :
- Paramètre n8n EXECUTIONS_PROCESS (par défaut : own, main) :
- Exécution de n8n via (Docker, npm, n8n cloud, application de bureau) :
- Système d’exploitation :
Salut @Aarush_Bisht
Pour éviter les plantages liés à la mémoire, tu dois te concentrer sur la réduction de l’« empreinte mémoire » de tes données au fur et à mesure qu’elles circulent dans le flux de travail.
A. Implémenter le traitement par lots (L’étape la plus importante) Si tu traites une grande liste d’éléments (par exemple, 1 000+ lignes d’une base de données ou d’une API), ne les envoie pas tous au nœud suivant en une seule fois.
- Utilise le nœud « Split In Batches » : Traite les éléments par petits groupes (par exemple, 50 ou 100 à la fois). Cela garantit que n8n ne conserve en mémoire active qu’un petit sous-ensemble de données à tout moment.
B. Évite les données « lourdes » en mémoire
- Limite les champs : Utilise un nœud Set ou un nœud Edit Fields pour supprimer les données inutiles au début du flux de travail. Si une API renvoie 50 champs mais que tu n’en as besoin que de 3, supprime immédiatement les 47 autres.
- Gestion des données binaires : Si tu travailles avec de gros fichiers (PDF, Images), évite de conserver plusieurs copies des données binaires dans le flux de travail. Utilise les nœuds « Read/Write Binary File » ou un stockage externe (comme S3 ou Google Drive) et transmets uniquement l’ID ou l’URL du fichier entre les nœuds.
C. Optimiser l’exécution des nœuds
- Évite les boucles volumineuses : Les boucles profondément imbriquées ou les appels récursifs peuvent consommer rapidement la pile et la mémoire du tas.
- Nœuds d’attente : Si tu appelles une API dans une boucle, ajoute un nœud Wait (même pour 1 seconde). Cela non seulement prévient le dépassement de limite de débit, mais peut aussi donner au garbage collector de Node.js une fenêtre pour libérer la mémoire inutilisée.
D. Surveillance et alertes
- Flux de travail d’erreur : Crée un « Flux de travail d’erreur » dédié (via les Paramètres du flux de travail) qui t’envoie une notification Slack ou Email dès qu’une défaillance se produit. Cela te permet d’intervenir manuellement avant que le système n’atteigne la limite du « Circuit Breaker » et ne désactive le flux de travail.
Cela fonctionnait bien depuis des mois, mais s’est crashé/dépublié un jour après seulement 3 échecs d’exécution différents. (J’ai implémenté 3 tentatives pour un nœud par exécution). La quantité de données n’est pas importante non plus (littéralement juste 50-60 lignes de données d’employés). J’ai implémenté la gestion des erreurs aussi, j’ai fait « toujours produire les données » et ensuite si une erreur est détectée, m’envoyer un message. La partie intéressante, c’est que ça n’a pas suivi ça non plus. Ni n’a essayé la tentative, juste s’est échoué et dépublié.
L’une de ces situations s’applique-t-elle :
- Charge utile anormalement volumineuse : L’un de ces 60 employés avait-il un champ (comme une section « Notes » ou « Bio ») qui contenait soudainement une énorme quantité de texte ou une image/fichier codé en base64 gigantesque ?
- Réponse API « infinie » : Une API externe que vous appelez a-t-elle retourné un énorme objet JSON (p. ex., 10 Mo+) pour un seul de ces 60 enregistrements ?
- Référence circulaire : Les données ont-elles créé une boucle qui a causé au moteur JavaScript de rencontrer une limite de « Débordement de pile » ou « Mémoire insuffisante » ?
Vérifiez vos journaux cloud
- Vérifiez l’historique d’exécution : Recherchez les 3 exécutions échouées. Ont-elles un statut
Error ou sont-elles simplement Running (bloquées) ou manquantes entièrement ? Si elles manquent ou restent bloquées dans « Running » malgré le flux de travail désactivé, cela confirme un plantage brutal.
- Inspectez les données : Examinez les données qui sont entrées dans le flux de travail hier. Comparez-les aux jours précédents. Recherchez toute chaîne de caractères anormalement volumineuse ou format inattendu dans ces 60 lignes.
- Vérifiez les nœuds « lourds » : Avez-vous des nœuds de code ? Une petite erreur logique dans un nœud de code (comme une boucle
while infinie) peut consommer toute la RAM disponible en quelques secondes, contournant tous les mécanismes de gestion d’erreurs intégrés à n8n.
50-60 lignes de données pour un employé.
et l’une des 3 qui ont échoué était un nœud de code JavaScript où j’essayais moi-même de réduire les dimensions des données.
{
“nodes”: [
{
“parameters”: {
“jsCode”: “\nconst updates = $node["Webhook"].json.body.data.fieldUpdatesIds.map(f => f.id);\n\nconst targetFields = [\n "work.site",\n "work.department",\n "work.siteId",\n "work.customColumns.column_1732603686850",\n "work.workChangeType",\n "work.title",\n "work.activeEffectiveDate",\n "work.reportsTo",\n "root.displayName"\n];\n\nconst check = updates.some(id => targetFields.includes(id));\n\nreturn [{check}];\n”
},
“type”: “n8n-nodes-base.code”,
“typeVersion”: 2,
“position”: [
-3104,
496
],
“id”: “7e8b7768-aa58-4218-98bb-24008a7ea4ef”,
“name”: “Code in JavaScript1”
}
],
“connections”: {
“Code in JavaScript1”: {
“main”: [
]
}
},
“pinData”: {},
“meta”: {
“instanceId”: “0f39d8fdd402ddce20d0eb724526828e8c2d8679170e3a08fe6cd471c799fab6”
}
}
Les logs pour ces 3 exécutions particulières ne peuvent pas être vérifiés car n8n dit que les logs ne sont pas enregistrés en raison de l’échec de l’exécution. (étrange, car les logs des échecs sont plus importants).
1 nœud a échoué, il était juste là pour obtenir un jeton d’authentification. Pas de boucle, juste une seule requête API. Le troisième (nœud HTTP) contenait certaines imageUrls en réponse mais pas d’images (basé sur les exécutions précédentes). Les trois ont échoué ensemble dans 3 exécutions différentes pour la même raison.
Pourrait-ce être une erreur du côté des serveurs de n8n ?
Très peu probable.
Votre code est logiquement simple et ne devrait pas faire planter un serveur avec 60 lignes de données. Cependant, il existe un risque de performance dans la façon dont il accède aux données :
const updates = $node["Webhook"].json.body.data.fieldUpdatesIds.map(f => f.id);
Utiliser $node["NodeName"] force n8n à conserver l’objet de données complet du nœud précédent dans le tas (heap) de mémoire active pendant toute la durée du workflow. Si votre charge utile Webhook est importante et que vous avez plusieurs nœuds qui font cela, vous multipliez l’utilisation de la mémoire.
Remplacez votre code JS actuel par cette version. Elle utilise la syntaxe moderne et ajoute une « vérification de sécurité » pour empêcher le nœud de planter si les données sont manquantes (ce qui causerait sinon une TypeError) :
// Utiliser la syntaxe moderne $(...).item pour une meilleure gestion de la mémoire
const webhookData = $("Webhook").item.json.body?.data?.fieldUpdatesIds;
if (!Array.isArray(webhookData)) {
return [{ check: false, error: "No fieldUpdatesIds found" }];
}
const updates = webhookData.map(f => f.id);
const targetFields = [
"work.site",
"work.department",
"work.siteId",
"work.customColumns.column_1732603686850",
"work.workChangeType",
"work.title",
"work.activeEffectiveDate",
"work.reportsTo",
"root.displayName"
];
const check = updates.some(id => targetFields.includes(id));
return [{ check }];
Pour vous assurer d’obtenir réellement des journaux quand quelque chose tourne mal :
- Allez dans Paramètres du workflow (l’icône d’engrenage).
- Assurez-vous que « Enregistrer les exécutions échouées » est ACTIVÉ.
- Réglez « Enregistrer les exécutions réussies » sur DÉSACTIVÉ (ou « Uniquement en cas d’erreur »). Cela libère les ressources de base de données et facilite l’identification des exécutions « problématiques ».
Puisque vous avez mentionné que le nœud HTTP avait imageUrls, vérifiez si l’une de ces URL renvoie des métadonnées massives ou si le corps de la réponse est anormalement important. Même si ce n’est pas l’image elle-même, une énorme réponse JSON peut causer un pic d’utilisation de la mémoire.
J’ai juste vérifié les exécutions défaillantes, c’était une sauvegarde par défaut. Les données JSON contenaient juste des URL d’images, rien de plus. J’ai aussi regardé les données que tous les nœuds reçoivent du webhook (oui, ce nœud de code traitait ces données). C’est un simple webhook d’événement Slack qui reçoit 20-30 lignes de métadonnées de requête API (dans les en-têtes) et 10 lignes de corps ainsi que d’autres informations en JSON. (Rien ne semble anormal). Mon problème est que si je m’absentais à tout moment et que cela se produisait, le système pourrait être indisponible pendant un certain temps.
Deux possibilités :
- Fuite cumulative : Sur 3 mois, de petites quantités de mémoire n’ont peut-être pas été correctement libérées. Finalement, l’utilisation mémoire « de base » est devenue si élevée qu’un minuscule webhook Slack l’a poussée au-delà de la limite.
- Concurrence : Si 5 ou 10 événements Slack arrivent à votre webhook à la même seconde exacte, n8n lance plusieurs exécutions parallèles. Même si chacune est petite, 10 processus simultanés peuvent faire monter la RAM en flèche et déclencher le crash.
Comme vous craignez que le système soit hors ligne pendant que vous êtes en congé, vous ne pouvez pas compter sur n8n pour se surveiller lui-même (car s’il plante, le moniteur plante aussi). Vous avez besoin d’une surveillance externe.
Utilisez un service gratuit comme Better Stack, UptimeRobot ou Cronitor.
- Créez un second workflow très simple dans n8n :
Webhook Trigger → Respond to Webhook (200 OK).
- Configurez le moniteur externe pour envoyer une requête à cette URL toutes les 5 ou 10 minutes.
- Si le moniteur reçoit une erreur 500 ou un timeout, il vous enverra immédiatement un email/SMS. Vous saurez que l’instance est hors ligne avant que votre workflow principal ne manque de données critiques.
En regardant votre capture d’écran des paramètres, vous avez « Enregistrer les exécutions de production réussies » défini sur « Enregistrer ».
- Changez cela à « Ne pas enregistrer ».
- Pourquoi ? Chaque fois qu’une exécution réussie est enregistrée, n8n doit conserver ces données en mémoire et les écrire sur le disque. Pour un webhook Slack à haute fréquence, cela crée un « renouvellement » constant en mémoire. En enregistrant uniquement les échecs, vous réduisez considérablement la charge sur l’instance.
Comme vos données sont objectivement petites et que vous fonctionnez depuis 3 mois, cela pourrait être un problème avec le « nœud » spécifique (le serveur physique) sur lequel votre instance est hébergée.
- Envoyez à l’équipe d’assistance du cloud n8n ou à help@n8n.io la capture d’écran de l’exécution « Interruption ».
- Dites-leur : « Mon workflow traite de très petites charges Slack, mais je vois des exécutions « Interruption » et le disjoncteur dépublie mon flux. Pouvez-vous vérifier si mon instance subit une pression mémoire ou si je dois être déplacé vers un autre hôte ? »
Puis-je faire quelque chose pour corriger les fuites cumulatives ? Comme redémarrer le flux de travail ou quelque chose de ce genre ? Désactiver pour les itérations réussies pourrait ne pas être une option pour moi (instance de l’entreprise, j’ai donc besoin de conserver les enregistrements complets au moins pour les derniers jours). La concurrence pourrait être un problème car les 3 exécutions échouées se sont produites ensemble (mais j’ai vu n8n gérer 8-10, voire davantage parfois). La surveillance externe pourrait ne pas être nécessaire car n8n lui-même envoie un message par mail pour dire qu’il a désactivé et nous sommes informés. (Je voulais dire, qui emporte son ordinateur portable professionnel en vacances 
)
Redémarrer le workflow lui-même ne résoudra pas la fuite ; le point de réinitialisation est l’instance en cours d’exécution ou le worker. Dans ce cas, l’indice le plus pertinent est que les trois défaillances se sont produites ensemble, non que le nœud Code soit lourd.
Vérifiez une fenêtre, aucune donnée d’employé nécessaire : les trois exécutions du webhook Slack ont-elles démarré dans les mêmes quelques secondes, et d’autres exécutions s’exécutaient-elles à ce moment ? Si oui, la limite suivante est une petite file d’attente/porte série avant le chemin de mise à jour des employés, donc Slack est reconnu rapidement mais un seul travail de mise à jour est traité à la fois. S’ils étaient espacés, traitez-le comme un incident Cloud/runtime et fournissez au support les trois ID d’exécution ainsi que l’horodatage de désactivation automatique.
Il se peut que ce soit un problème de concurrence. Y a-t-il un moyen d’y remédier ? Par exemple, peut-on retarder les exécutions qui arrivent en même temps ?
Oui, mais ne placez pas le délai après les nœuds lourds. Si trois événements Slack ont déjà démarré le workflow complet, un nœud Wait laisse simplement trois exécutions actives en même temps.
Gardez l’intake Slack minuscule : recevez l’événement, accusez-le de réception, et mettez seulement l’ID/le corps de l’événement nécessaires à la mise à jour des employés derrière une porte une-à-la-fois. Traitez ensuite cette deuxième partie selon un calendrier ou une file d’attente. Vous pouvez toujours conserver les enregistrements d’exécution ; ce qu’il faut réduire, c’est le travail parallèle dans la branche employee-update, non la rétention d’enregistrements en elle-même.
Je suppose que l’événement était déjà petit puisque les données webhook n’étaient pas volumineuses (JSON de maximum 50-60 lignes) et nous n’avions besoin que de quelques champs (ce que le nœud de code effectuait — réduction dimensionnelle des données). C’est juste que la requête est arrivée en parallèle. J’ai vu des requêtes HTTP recevoir des MBs de données sans planter. De toute façon, je vais essayer de transmettre cela à l’équipe n8n (si possible pour moi). Merci de votre aide, je vais essayer de mettre en œuvre ces suggestions dans les futurs workflows.
