Déboguer un Worker qui génère des erreurs 500 en production
Quand l'utiliser : Le taux d'erreur de votre Worker a grimpé en flèche. Vous voulez des logs, les déploiements récents et un diff de ce qui a changé — sans ouvrir le tableau de bord.
Prérequis
- Compte Cloudflare avec OAuth connecté à votre client MCP — Le premier appel outil déclenche OAuth ; accordez les scopes 'Workers Observability' et 'Workers Bindings'
Déroulement
-
Tail des logs récents du Worker filtrés par erreurTail logs pour le Worker 'api-edge' au cours des 15 dernières minutes. Filtrez pour le statut >= 500. Groupez par les 100 premiers caractères du message d'erreur.✓ Copié→ Principaux modèles d'erreurs avec comptages et horodatages
-
Lister les déploiements récentsListez les 5 derniers déploiements de 'api-edge'. Affichez l'heure de déploiement, l'auteur et le hash de version.✓ Copié→ Chronologie de déploiement — à corréler avec le début des erreurs
-
Revenir à la version précédente si nécessaireLe pic d'erreurs commence après le déploiement à 14:22. Revenez 'api-edge' à la version précédente. Demandez-moi une confirmation avant de procéder.✓ Copié→ Invite de confirmation avant une action destructive
Résultat : Un Worker de production restauré, avec une note postmortem claire 'le déploiement X a causé les erreurs Y'.
Pièges
- Le tail des logs est en temps réel uniquement ; peut manquer une rafale déjà passée — Pour les fenêtres historiques, utilisez plutôt les outils MCP Logpush ou Analytics Engine
- Le revirement ne migre pas l'état D1/KV — Si le mauvais déploiement a exécuté des migrations, revenir à une version antérieure du Worker seul n'est pas suffisant — vous pourriez avoir besoin d'une restauration D1 également