Nous avons un problème avec les webhooks sur plusieurs workflows. Il y a plusieurs occurrences, toujours autour de 12h00/12h00 ∼ 12h20, où certains webhooks ne sont tout simplement pas appelables et n8n affiche « There was a problem executing the workflow ». Ou le backend s’exécute avec un timeout, aucune exécution n’est enregistrée (même si l’enregistrement des exécutions est activé). Il n’y a pas de message d’erreur plus détaillé, juste celui-ci générique. Y a-t-il un endroit où je peux voir plus d’informations sur cette erreur sur mon instance n8n?
Le seul endroit pour trouver l’erreur « réelle » est dans les Journaux du service Render.com.
Quoi chercher : Allez à votre tableau de bord Render →→ votre service n8n →→ Logs.
Mots-clés spécifiques : Recherchez SQLITE_BUSY, database is locked, Out of Memory, Killed ou Segmentation fault autour des timestamps 12:00 AM/PM.
Conseil pratique : Pour obtenir encore plus de détails, ajoutez la variable d’environnement N8N_LOG_LEVEL=debug à vos paramètres Render et redémarrez. Cela forcera n8n à imprimer des événements internes plus détaillés dans les journaux Render.
D’après votre description, ce comportement est généralement causé par l’une de ces deux choses : Verrouillage de la base de données ou Épuisement de la mémoire (OOM).
Voici la correction recommandée :
Migrer vers PostgreSQL : SQLite n’est pas conçu pour la concurrence en production. Render fournit une base de données PostgreSQL gérée. La migration vers Postgres élimine complètement le problème de « verrou d’écriture » et est la recommandation standard pour toute instance n8n gérant des webhooks en production. Cela résoudra définitivement les timeouts à 12:00 et les erreurs génériques « problème lors de l’exécution ».
Désolé, j’ai fait une erreur, nous utilisons déjà Postgres.
La mémoire ne monte pas non plus à ces moments-là et il n’y a pas d’autres entrées de journal dans le service de rendu que celles-ci « There was a problem executing the workflow ».
@Florian_Glappa Je m’attendrais à ce que cette erreur déclenche quelque chose dans les logs de n8n. Est-il possible que Render effectue une sauvegarde / snapshot autour de minuit ? Une fenêtre de 20 minutes autour du même type d’horaire pointe plutôt vers quelque chose d’environnemental plutôt qu’un bug côté application.
En complément de l’angle environnemental de Jon — il y a aussi un motif côté application qui correspond exactement à vos symptômes et n’a pas encore été mentionné : 0 0,12 * * * est l’une des expressions cron les plus courantes qui existent. Si un workflow quelconque sur votre instance (pas seulement les workflows défaillants) a un Schedule Trigger qui se déclenche à 00:00 et 12:00, un travail lourd deux fois par jour peut brièvement saturer l’instance, et les webhooks entrants sont ce qui échoue visiblement. Cela vaut la peine de faire un inventaire rapide de chaque Schedule Trigger dans tous les workflows, puis de vérifier la liste des exécutions filtrée à ces fenêtres temporelles : une exécution planifiée est-elle toujours en cours quand les webhooks s’arrêtent ?
La deuxième chose qui correspond à votre « aucune donnée d’exécution enregistrée malgré la sauvegarde activée » : épuisement du pool de connexions Postgres. Le pool par défaut de n8n par processus principal est petit, et quand plusieurs exécutions commencent au même moment, le pool s’épuise — les nouvelles exécutions peuvent alors échouer avant que n8n ne parvienne à écrire quoi que ce soit dans la table des exécutions, et l’erreur revient à l’appelant du webhook sans beaucoup de traces dans les logs du service. Cela expliquerait pourquoi vous voyez presque rien dans les logs Render. Deux vérifications : augmentez DB_POSTGRESDB_POOL_SIZE (par exemple à 10) et voyez si le motif change, et consultez les logs côté Postgres (les logs de la base de données Render, pas les logs du service n8n) pour les erreurs de connexion ou les pics de latence à ces heures-là — une sauvegarde de base de données gérée s’y afficherait aussi, ce qui confirmerait la théorie de Jon sans devoir deviner.
Et puisque c’est tellement prévisible : regardez-le en direct une fois. docker logs -f (avec debug activé, comme kjooleng l’a suggéré) de 11:55 à 12:25 vous en apprendra plus qu’un jour de défilement, plus filtrer la liste des exécutions par statut « crashed » — celles-ci ne s’affichent pas toujours où vous vous y attendez.
Si l’inventaire cron révèle un travail deux fois par jour, la correction habituelle est simplement de le déplacer à une heure inhabituelle (style 03:17) et de le regrouper. Décaler les plannings à des minutes inhabitelles est une bonne habitude sur n’importe quel n8n à instance unique de toute façon.
Hé, c’était vraiment un bon indice, merci ! J’ai trouvé une tâche cron qui démarre à 00:05 et 12:05 et qui s’exécute habituellement pendant 15 minutes en utilisant une quantité ridicule de mémoire. J’ai refactorisé ça maintenant, je pense que c’était ça. Merci beaucoup !
J’ai aussi augmenté la taille du pool de connexions.
