Ce que c’est
Un poste de tri gratuit pour les livraisons de webhooks qui ont échoué. Il lit un simple journal et en fait une liste claire de dossiers, de causes et de prochaines étapes.
Tri des webhooks en échec
Chaque webhook en échec a droit à son autopsie.
Collez le journal de livraison de Stripe, GitHub, Shopify ou de votre propre file. Webhook Morgue étiquette chaque échec avec sa cause, indique ceux qu’on peut rejouer sans risque et prépare un plan de relance avec des délais raisonnables.
Pour qui
Les développeurs et les ingénieurs d’astreinte qui reçoivent des webhooks de plateformes de paiement, de commerce ou de code et doivent vite décider quoi relancer.
Ce que ça règle
Les relances à l’aveugle. Rejouer un 401 ou un 410 ne crée que de nouveaux échecs, alors qu’un 500 ou un délai dépassé demande souvent une simple relance posée. L’outil fait la différence.
Dossier
Une livraison par ligne. Séparez l’événement, le code de statut et une note par une barre verticale, ou collez des lignes JSON.
Ligne d’exemple : invoice.paid | 500 | upstream timeout | 14:02
Aucun dossier pour l’instant
Chargez le journal de démo pour voir une autopsie complète de huit livraisons, ou collez le vôtre.
Le journal est lu dans votre navigateur. Rien n’est envoyé.
Vérification de signature
La plupart des erreurs 401 viennent d’une signature qui ne correspond pas. Collez le corps brut, le secret et l’entête de signature pour voir s’ils concordent.
Utilisez un secret de test. La vérification se fait dans votre navigateur et le secret ne quitte jamais la page.
HMAC SHA 256 calculé avec l’API Web Crypto dans votre navigateur.
Causes du décès
Ce que signifie en général chaque échec et ce qu’il faut faire.
Délai dépassé
Rejouez avec des délais croissants. Le gestionnaire doit répondre en quelques secondes et confier le travail lent à une file.
Récepteur en panne
Rejouez avec des délais croissants une fois le récepteur rétabli. Consultez ses journaux d’erreurs pour cet événement.
Limite de débit atteinte
Attendez le délai demandé par le récepteur, puis rejouez lentement.
Signature ou accès refusé
Ne rejouez pas tout de suite. Vérifiez le secret de signature des deux côtés, puis rejouez une fois.
Point d’accès disparu
Ne rejouez pas. Pointez le webhook vers le nouveau point d’accès ou supprimez l’abonnement.
Contenu refusé
Ne rejouez pas tel quel. Corrigez le gestionnaire ou le schéma, puis rejouez une fois.
Redirigé
Un récepteur ne devrait pas rediriger. Remplacez l’adresse du webhook par l’adresse finale.
Livré
Rien à faire. Cette livraison est arrivée.
Mode d’emploi
Exportez le journal
Copiez les livraisons en échec depuis le tableau de bord du fournisseur ou votre propre file. Le nom de l’événement et le code de statut suffisent.
Lancez l’autopsie
Chaque ligne devient un dossier étiqueté, avec une cause du décès et une étape suivante claire.
Suivez le plan
Rejouez les dossiers sûrs selon le calendrier proposé, corrigez les autres d’abord, puis partagez le rapport avec l’équipe.
Ce qu’il ne fait pas
- Il ne se connecte pas à votre fournisseur et ne rejoue rien à votre place. Il vous dit quoi rejouer et quand.
- Il ne voit pas l’intérieur du récepteur. Un 500 signifie que votre code a échoué, le journal seul ne dit pas pourquoi.
- Il ne lit que les formats montrés ici. Un journal inhabituel demandera sans doute un petit nettoyage.
Questions
Mon journal quitte mon navigateur ?
Non. L’analyse, le plan et la vérification de signature tournent dans votre navigateur.
Pourquoi ne pas tout rejouer ?
Rejouer un 401, un 404 ou un 422 échoue de la même façon et peut déclencher des alertes ou un blocage. Corrigez la cause, puis rejouez une fois.
Pourquoi les attentes n’ont pas toutes la même durée ?
Un petit décalage aléatoire, appelé jitter, évite que de nombreuses relances frappent un serveur en convalescence à la même seconde.