Exécution bloquée : trouver les stuck executions, configurer les timeouts

Dans n8n, vous voyez une exécution qui ne se termine tout simplement pas. Le statut reste bloqué sur « Running » ou « Waiting » alors que le workflow aurait dû se terminer depuis longtemps. C'est ce qu'on appelle une exécution bloquée ou « stuck », et c'est plus qu'un simple problème cosmétique : par défaut, selon la référence officielle des variables d'exécution n8n n'a aucune limite de temps, EXECUTIONS_TIMEOUT est réglé sur -1 par défaut. Sans configuration personnelle, une exécution peut donc théoriquement tourner indéfiniment et bloquer des ressources, des emplacements de worker et, en mode queue, des files d'attente entières.

Cet article vous montre comment reconnaître les exécutions bloquées, quelles en sont les causes typiques et comment définir, avec EXECUTIONS_TIMEOUT et EXECUTIONS_TIMEOUT_MAX, une limite de temps propre adaptée à votre instance. Mise à jour : juillet 2026.

Comment reconnaître les exécutions bloquées ?

• Dans l'onglet « Executions », le statut reste durablement sur « Running » ou « Waiting », alors que des exécutions comparables se terminent normalement en quelques secondes ou minutes.
• L'indicateur de durée d'exécution continue d'augmenter sans qu'aucune nouvelle entrée de log ni changement de nœud ne soit visible.
• En mode queue, de nouvelles exécutions s'accumulent dans la file d'attente, car un worker est bloqué par l'exécution bloquée et, selon la configuration via N8N_CONCURRENCY_PRODUCTION_LIMIT, n'est pas autorisé à démarrer d'autres exécutions en parallèle.
• Le serveur consomme nettement plus de mémoire ou de CPU sans que cela puisse s'expliquer par la charge actuelle.

Une seule exécution bloquée semble d'abord inoffensive. En pratique, quelques exécutions de ce type suffisent déjà à ralentir sensiblement toute une instance n8n, surtout lorsque plusieurs workflows partagent le même pool de workers.

Causes typiques des exécutions bloquées

• Aucun timeout défini : sans votre propre configuration EXECUTIONS_TIMEOUT, aucune limite automatique ne s'applique, et un seul nœud défaillant peut maintenir l'exécution entière ouverte.
• Appels externes sans timeout propre : un nœud HTTP Request qui attend une API très lente ou qui ne répond pas reste bloqué jusqu'à ce que le service distant réagisse ou que n8n intervienne lui-même.
• Nœuds Wait mal configurés : un nœud Wait qui attend un événement externe qui ne se produit jamais maintient l'exécution en permanence dans le statut « Waiting ».
• Sous-workflows bloqués : si votre workflow principal appelle un sous-workflow, le blocage de ce dernier se répercute directement sur l'exécution parente.
• Problèmes en mode queue : si la connexion entre le processus principal et le worker est perturbée, par exemple à cause d'un accès Redis instable, les exécutions restent à l'état « Running » sans que le worker les traite réellement encore.

Bien configurer EXECUTIONS_TIMEOUT et EXECUTIONS_TIMEOUT_MAX

Pour une limite de temps fiable, selon le guide de configuration des timeouts de workflow, deux variables d'environnement sont déterminantes :

• EXECUTIONS_TIMEOUT : définit la limite de temps par défaut en secondes, applicable à tous les workflows sauf si une limite individuelle a été définie. La valeur par défaut est -1, c'est-à-dire désactivée. Une valeur de 3600 limite chaque exécution à une heure.
• EXECUTIONS_TIMEOUT_MAX : définit la limite absolue en secondes, qui s'applique même si un workflow individuel a défini un timeout personnel plus élevé. Selon la référence, la valeur par défaut est de 3600 secondes.

Important pour comprendre comment le timeout intervient techniquement : si le workflow s'exécute dans le processus principal, la documentation indique qu'un timeout doux se produit, qui n'agit qu'après la fin du nœud actuellement actif. Si l'exécution se déroule en revanche dans un processus séparé, par exemple en mode queue sur un worker, n8n tente d'abord également un arrêt doux, puis force un arrêt dur. Pour vous, cela signifie : un timeout n'est pas un interrupteur instantané, mais un mécanisme échelonné qui termine le travail en cours aussi proprement que possible avant d'intervenir durement.

Chaque workflow peut définir dans ses propres paramètres un timeout personnel, plus bas. Celui-ci reste toutefois toujours plafonné par EXECUTIONS_TIMEOUT_MAX, de sorte qu'un workflow individuel ne peut pas dépasser la limite globale. Vous gardez ainsi le contrôle de la durée d'exécution maximale sans devoir sécuriser individuellement chaque workflow.

Nettoyer les données d'exécution pour garder une base de données légère

Au-delà de la simple limite de temps, il vaut la peine de se pencher sur la conservation des données d'exécution, car une base de données surchargée complique aussi le diagnostic des exécutions bloquées. Selon la référence, n8n nettoie automatiquement les données d'exécution :

• EXECUTIONS_DATA_PRUNE (par défaut : activé) détermine si les exécutions terminées sont supprimées automatiquement.
• EXECUTIONS_DATA_MAX_AGE détermine après combien d'heures les anciennes exécutions sont considérées comme candidates à la suppression, la valeur par défaut correspondant à 14 jours.
• Les exécutions actives dont le statut est « new », « running » ou « waiting » sont explicitement exclues du nettoyage, tout comme les exécutions auxquelles vous avez ajouté des tags ou des évaluations.

Ces mécanismes de protection sont une arme à double tranchant : ils empêchent une exécution encore en cours d'être supprimée par erreur, mais dans le même temps, une exécution réellement bloquée reste ainsi durablement dans la base de données tant qu'aucun timeout ne la termine normalement. C'est précisément pour cela que la combinaison d'un EXECUTIONS_TIMEOUT judicieux et d'un nettoyage des données fonctionnel est importante, afin que les exécutions bloquées ne s'accumulent pas sans être remarquées.

Checklist pratique

• Vérifiez d'abord dans l'onglet Executions quelles exécutions sont réellement bloquées sur « Running » ou « Waiting » depuis des heures ou des jours.
• Définissez EXECUTIONS_TIMEOUT sur une valeur réaliste pour vos workflows réguliers les plus longs, plus une marge de sécurité.
• Définissez EXECUTIONS_TIMEOUT_MAX de manière à ce que même les workflows individuels particulièrement longs ne puissent pas tourner indéfiniment.
• Pour les nœuds connectés à des services externes, comme HTTP Request ou les points d'attente Webhook, vérifiez s'il serait pertinent d'y ajouter un timeout propre.
• En mode queue, surveillez également la connexion à Redis et la charge de vos workers, car un worker bloqué provoque des symptômes bien différents d'un simple workflow bloqué.

Si vous exploitez n8n comme un collaborateur numérique dans votre entreprise, un timeout correctement configuré fait partie de l'équipement de base, tout comme un œil sur les limites de concurrency et le nettoyage des données. Une fois ces réglages correctement effectués, vous n'avez généralement plus besoin de vous occuper manuellement des exécutions bloquées. Si vous avez besoin d'aide pour cela, ou si vous souhaitez rendre votre instance n8n fondamentalement plus stable, NordFlux vous accompagne dans la mise en place et l'exploitation de workflows n8n.

Questions fréquentes

Que signifie le statut « Waiting » pour une exécution n8n ?

« Waiting » indique que l'exécution attend, à un point donné du workflow, un événement externe, par exemple une réponse d'un nœud Wait ou un appel webhook en attente. Si ce statut persiste au-delà de la durée d'exécution attendue, cela indique un événement qui ne se produit jamais, et l'exécution reste effectivement bloquée jusqu'à ce qu'un timeout la termine.

Quelle valeur dois-je définir pour EXECUTIONS_TIMEOUT ?

Il n'existe pas de valeur universellement correcte, elle dépend de vos workflows réguliers les plus longs. Comme point de départ, il est utile de mesurer la durée normale de votre automatisation la plus exigeante et de l'arrondir généreusement, par exemple deux à trois fois. Cela laisse suffisamment de marge pour les fluctuations normales, tout en garantissant que les exécutions réellement bloquées soient tout de même terminées de manière fiable.

EXECUTIONS_TIMEOUT met-il fin immédiatement à une exécution ?

Non, selon la documentation n8n, un arrêt doux se produit d'abord. Dans le processus principal, n8n attend que le nœud en cours d'exécution soit terminé ; dans les processus séparés, après une tentative douce, un arrêt dur est également forcé après un court délai d'attente. La transition se fait donc de manière échelonnée et non abrupte.

Un workflow individuel peut-il avoir un timeout plus élevé que celui autorisé par EXECUTIONS_TIMEOUT_MAX ?

Non. EXECUTIONS_TIMEOUT_MAX définit la limite absolue pour l'ensemble de l'instance. Même si un workflow a défini dans ses propres paramètres un timeout individuel plus élevé, cette valeur est plafonnée par EXECUTIONS_TIMEOUT_MAX, de sorte qu'aucun workflow ne peut dépasser la limite globale.

Les exécutions bloquées sont-elles automatiquement supprimées de la base de données ?

Pas tant qu'elles sont actives. n8n exclut explicitement les exécutions ayant le statut « new », « running » ou « waiting » du nettoyage automatique via EXECUTIONS_DATA_PRUNE. Une exécution réellement bloquée reste donc en place jusqu'à ce qu'un timeout configuré la termine ou que vous l'annuliez manuellement.