1. URL de test au lieu de l'URL de production
Le nœud Webhook expose deux adresses. L'URL de test (/webhook-test/…) ne fonctionne que pendant que vous cliquez sur « Listen for test event », pour un seul appel. L'URL de production (/webhook/…) ne fonctionne que si le workflow est actif. Un formulaire configuré avec l'URL de test marche pendant vos essais, puis plus jamais.
2. Le workflow n'est pas actif
Un workflow désactivé, volontairement ou après une importation, ne répond pas sur l'URL de production. Vérifiez l'interrupteur en haut à droite. Après une restauration ou une migration, tous les workflows peuvent être inactifs.
3. WEBHOOK_URL mal réglée derrière un reverse proxy
En auto-hébergement, n8n construit les URL affichées à partir de la variable WEBHOOK_URL. Si elle est absente, n8n affiche une adresse interne (par exemple http://localhost:5678) que l'émetteur ne peut pas joindre.
WEBHOOK_URL=https://n8n.mondomaine.fr/
N8N_PROXY_HOPS=14. Méthode HTTP ou chemin différents
Le nœud n'accepte que la méthode configurée (GET, POST…). Un émetteur qui envoie un POST sur un webhook réglé en GET reçoit une erreur 404. Même chose si le chemin a été modifié dans le nœud sans être mis à jour chez l'émetteur.
5. Conflit de chemin entre deux workflows
Deux workflows actifs ne peuvent pas partager le même chemin et la même méthode. Le second n'est pas enregistré. Cela arrive souvent après la duplication d'un workflow.
6. Le reverse proxy ou le pare-feu bloque
Nginx, Traefik ou Cloudflare peuvent rejeter la requête avant n8n : taille de corps trop grande, délai dépassé, règle de pare-feu, protection anti-robots. Cherchez la requête dans les journaux du proxy : si elle n'y est pas, le problème est en amont.
7. L'émetteur a cessé d'envoyer
Le webhook fonctionne, mais le service tiers a désactivé l'envoi après plusieurs échecs, ou un jeton a expiré de son côté. Beaucoup de services (Stripe, Calendly, les boutiques en ligne) désactivent un webhook qui a répondu en erreur trop souvent.
| Symptôme | Cause probable | Vérification |
|---|---|---|
| 404 « webhook not registered » | Workflow inactif, mauvaise URL ou méthode | Interrupteur actif, URL /webhook/, méthode |
| Rien dans les exécutions | Requête bloquée en amont | Journaux du proxy et du service émetteur |
| L'URL affichée contient localhost | WEBHOOK_URL absente | Variables d'environnement du conteneur |
| Marchait en test, plus en production | URL de test utilisée | Remplacer /webhook-test/ par /webhook/ |
Éviter que ça se reproduise
Un webhook qui cesse de recevoir des requêtes ne produit aucune erreur : c'est une panne silencieuse. La parade est un contrôle de volume (alerte si aucune requête reçue depuis X heures en journée) et un workflow d'erreur pour les échecs. Le bilan de santé n8n repère aussi les webhooks sans authentification.
Questions fréquentes
Pourquoi mon webhook n8n renvoie-t-il une erreur 404 ?
Parce que n8n ne connaît pas ce chemin pour cette méthode : workflow inactif, URL de test utilisée en production, méthode HTTP différente ou chemin modifié.
Faut-il redémarrer n8n après avoir changé WEBHOOK_URL ?
Oui, les variables d'environnement sont lues au démarrage. Recréez le conteneur si vous utilisez Docker Compose.
Comment être prévenu si un webhook ne reçoit plus rien ?
Avec un contrôle de volume : un flux planifié compte les exécutions récentes et alerte si le nombre tombe à zéro pendant les heures ouvrées, ou un service de signal de vie appelé à chaque réception.