Bonjour,
J’éprouve des problèmes récurrents de « connexion perdue » / « hors ligne » en utilisant n8n Cloud via l’interface web, et je souhaite signaler ce problème car il ne semble pas être causé par ma configuration ou ma connexion Internet.
Mes workflows sont relativement simples :
- Je n’ai pas un grand nombre de workflows
- Les workflows ne sont pas particulièrement longs ou complexes
- La plupart d’entre eux sont des workflows de scraping/automatisation planifiés
- Le problème se produit souvent au niveau des nœuds HTTP Request
Voici ce qui se passe :
Alors qu’un workflow est en cours d’exécution, l’interface affiche soudainement « Hors ligne » ou perd la connexion ; parfois l’exécution s’arrête avec des messages liés à la mémoire ou à une exécution interrompue. Malgré cela, c’est toujours après une perte de connexion, et néanmoins, si j’exécute les mêmes workflows manuellement un par un, ils se terminent généralement avec succès.
J’ai déjà repensé mon architecture pour réduire la charge :
- Workflows séparés au lieu de chaîner plusieurs sous-workflows ensemble
- Ajout de nouvelles tentatives uniquement sur les nœuds d’API externes
- Réduction de la complexité d’exécution
- Échelonnement des temps d’exécution entre les workflows
Même après ces optimisations, j’éprouve toujours occasionnellement des pertes de connexion aléatoires.
Puisque j’utilise n8n Cloud directement depuis le navigateur, j’aimerais savoir :
- Si c’est un problème connu
- S’il existe des limitations de stabilité sur le plan Starter
- Ou s’il existe une configuration recommandée pour éviter ces déconnexions
Merci de votre aide.
Décrivez le problème/l’erreur/la question
Quel est le message d’erreur (le cas échéant) ?
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 :
Bienvenue dans la communauté n8n @Raul_Martin_Acebes
Je séparerais d’abord le message « hors ligne » du navigateur de l’exécution du workflow elle-même, en évitant d’exécuter ces workflows depuis l’éditeur pour les longues tâches de scraping. Maintenez-les actifs avec un Schedule Trigger, puis vérifiez l’historique d’exécution une fois qu’ils sont terminés. Si le navigateur se déconnecte mais que l’exécution continue, c’est surtout un problème d’interface utilisateur/session.
Pour les parties HTTP Request, j’ajouterais du batching/pagination et des chunks plus petits au lieu de récupérer trop de données en une seule requête. La documentation de n8n mentionne l’utilisation du batching pour réduire la taille des requêtes et ajouter des pauses entre les appels. Stockisez également la progression entre les étapes, afin qu’une exécution échouée puisse reprendre au lieu de recommencer à zéro.
Si les exécutions s’arrêtent vraiment avec des erreurs de mémoire/interruption, je capturerais l’ID d’exécution, l’horodatage, le nom du workflow et le nœud défaillant, puis je comparerais si cela se produit toujours avec la même taille de réponse HTTP ou le même endpoint.
Bienvenue dans la communauté @Raul_Martin_Acebes! La configuration que tu as décrite est réfléchie et tu as clairement déjà bien isolé le problème.
En m’appuyant sur ce que @tamy.santos a dit, je veux ajouter quelques points supplémentaires spécifiques aux workflows de web scraping sur n8n Cloud:
1. n8n Cloud a des limites de délai d’exécution
Sur le plan Starter, les workflows expirent après 1 heure. Si tes workflows de scraping accèdent à plusieurs endpoints dans des boucles, ils peuvent silencieusement atteindre cette limite et s’arrêter. Le navigateur affichant “offline” (hors ligne) est souvent juste la session WebSocket qui se ferme, mais le vrai coupable est le délai d’exécution. Vérifie l’historique d’exécution dans Paramètres > Exécutions pour voir s’ils affichent “Erreur” avec un message de délai dépassé.
2. Ajoute un nœud Wait entre les appels HTTP Request
Pour les workflows de scraping, ajoute un nœud Wait (défini sur 1-2 secondes) entre les lots d’appels HTTP. Cela évite les pics de mémoire et réduit la probabilité qu’une seule requête lourde bloque l’exécuteur:
Loop > HTTP Request > Wait (1s) > itération suivante
3. Utilise l’option “Continue on fail” sur les nœuds HTTP Request
Avec “Continue on fail” activé + “Always Output Data” coché, une seule requête échouée ne tuera pas l’exécution entière. Tu peux filtrer les éléments échoués par la suite.
4. Divise les gros travaux de scraping en exécutions planifiées plus petites
Au lieu d’un workflow qui scrape 1000 éléments, divise en lots de 100-200 par exécution avec un Schedule Trigger toutes les 15 minutes. Beaucoup plus stable sur Cloud.
Peux-tu partager à peu près combien de requêtes HTTP sont dans une seule exécution de workflow et quel plan tu utilises? Cela m’aidera à affiner le diagnostic.
Merci beaucoup pour les suggestions.
J’ai implémenté le traitement par lots avec les nœuds Loop Over Items + Wait et les workflows sont définitivement plus stables maintenant. Depuis que j’ai fait ça, ils ne se dépublieront plus automatiquement et la plupart des exécutions se terminent correctement même quand certains éléments échouent.
Cependant, je rencontre encore occasionnellement un autre problème qui semble indépendant de la mémoire/charge du workflow lui-même :
-
L’éditeur affiche soudainement “Hors ligne” même si je n’exécute aucun workflow.
-
Je reçois parfois des erreurs aléatoires 502 comme :
-
Pendant ce temps, je perds temporairement l’accès à la liste des workflows/l’interface utilisateur
-
Cela peut aussi se produire quand aucun workflow n’est en cours d’exécution
Donc à ce stade, ça ressemble plus à un problème d’instabilité du Cloud/interface utilisateur/session/backend plutôt qu’à un épuisement de la mémoire du workflow.
Connaissez-vous la cause de ce problème ? Je rencontre cela fréquemment pendant la journée et j’ai une bonne connexion Internet.
@Raul_Martin_Acebes
Cela semble plutôt être une défaillance temporaire entre le navigateur, le frontend, le backend de n8n et le proxy/cloud, ou une certaine instabilité de l’environnement Cloud lui-même. J’essaierais de capturer l’heure exacte du problème, les erreurs de la console/réseau du navigateur et de valider si cela se produit également dans un autre navigateur ou une fenêtre incognito. Si l’erreur persiste malgré tout, j’enverrais ces informations au support, car ils pourront vérifier les logs du backend/proxy relatifs aux erreurs 502 de leur côté.
Comment puis-je contacter le support ? J’essaie de résoudre cette erreur, mais je n’y arrive pas.
Deux choses distinctes se produisent ici, et il vaut la peine de les séparer car l’une d’elles n’est probablement pas un vrai problème.
La bannière « Hors ligne » dans l’éditeur signifie simplement que votre navigateur perd sa connexion en direct à n8n Cloud — le WebSocket qui diffuse la progression de l’exécution vers l’interface utilisateur. Cela n’arrête pas l’exécution. Les exécutions planifiées s’exécutent côté serveur que votre onglet soit connecté ou non, donc vous pouvez ignorer la plupart du bruit « hors ligne ». La partie qui compte vraiment, ce sont les erreurs de mémoire / exécution interrompue.
Cela ressemble à un dépassement du plafond de mémoire, qui sur le plan Starter est assez bas. Le scraping est le déclencheur classique : une requête HTTP récupérant une page HTML complète ou une grosse réponse JSON la garde entière en mémoire, et si cela traverse plusieurs nœuds en aval — ou si quelques exécutions planifiées se chevauchent — vous dépassez la limite et l’exécution est arrêtée. Cela explique aussi pourquoi les exécuter manuellement une à la fois fonctionne : pas de chevauchement, faible pic de mémoire.
Voici ce que j’essayerais, dans cet ordre :
- Juste après chaque requête HTTP, ajoutez un nœud Set/Edit Fields (ou un petit nœud Code) qui conserve uniquement les champs dont vous avez besoin et supprime la réponse brute. Traîner le corps de la page complète dans tout le workflow est généralement ce qui consomme la mémoire.
- Traiter par lot — Boucle sur les éléments / Diviser en lots — au lieu de tout récupérer et conserver à la fois. Cela maintient le pic de mémoire stable.
- Assurez-vous que deux exécutions planifiées ne peuvent pas se chevaucher. L’échelonnement aide, mais si une exécution prend plus longtemps que l’intervalle jusqu’au prochain déclenchement, elles s’empilent. Élargissez les intervalles.
Si vous faites tout cela et continuez à rencontrer des problèmes, c’est vraiment le plan — Pro offre plus de marge de mémoire. Mais je réduirais d’abord la charge utile ; les flux de scraping rétrécissent presque toujours beaucoup une fois que vous arrêtez de traîner la réponse brute partout.