Que fait Canary Watch — Surveillance post-déploiement ?
Quand l'utiliser
- Après un déploiement en production ou en staging
- Après la fusion d'une PR risquée
- Lorsque vous voulez vérifier qu'un correctif a réellement résolu le problème
- Surveillance continue pendant une fenêtre de lancement
- Après des mises à jour de dépendances
Comment ça fonctionne
Surveille une URL déployée pour détecter des régressions. S'exécute en boucle jusqu'à ce qu'elle soit arrêtée ou que la fenêtre de surveillance expire.
Ce qu'elle surveille
1. Statut HTTP — la page renvoie-t-elle 200 ?
2. Erreurs console — de nouvelles erreurs qui n'étaient pas là avant ?
3. Échecs réseau — appels API échoués, réponses 5xx ?
4. Performances — régression LCP/CLS/INP par rapport à la référence ?
5. Contenu — des éléments clés ont-ils disparu ? (h1, nav, footer, CTA)
6. Santé des API — les endpoints critiques répondent-ils dans les délais SLA ?
7. Actifs statiques — les requêtes JS, CSS, images et polices renvoient-elles 2xx/3xx avec les types de contenu attendus ?
8. Flux SSE — les endpoints event-stream se connectent-ils et reçoivent-ils un événement initial ou un heartbeat ?
Modes de surveillance
Vérification rapide (par défaut) : passage unique, rapporte les résultats
/canary-watch https://myapp.com
Surveillance soutenue : vérifie toutes les N minutes pendant M heures
/canary-watch https://myapp.com --interval 5m --duration 2h
Mode comparaison : compare staging et production
/canary-watch --compare https://staging.myapp.com https://myapp.com
Seuils d'alerte
critical: # alerte immédiate
- Statut HTTP != 200
- Nombre d'erreurs console > 5 (nouvelles erreurs uniquement)
- LCP > 4s
- Endpoint API renvoie 5xx
- Actif statique renvoie 4xx/5xx
- Endpoint SSE ne peut pas se connecter ou se déconnecte avant le premier heartbeat
warning: # signalé dans le rapport
- LCP augmenté > 500ms par rapport à la référence
- CLS > 0.1
- Nouveaux avertissements console
- Temps de réponse > 2x la référence
- Type de contenu d'actif statique modifié de manière inattendue
- Latence du heartbeat SSE > 2x la référence
info: # journalisation uniquement
- Variation de performance mineure
- Nouvelles requêtes réseau (scripts tiers ajoutés ?)
Notifications
Lorsqu'un seuil critique est franchi :
- Notification de bureau (macOS/Linux)
- Optionnel : webhook Slack/Discord
- Journalisation dans
~/.claude/canary-watch.log
Sortie
## Rapport Canary — myapp.com — 2026-03-23 03:15 PST
### Statut : SAIN ✓
| Vérification | Résultat | Référence | Écart |
|--------------|----------|-----------|-------|
| HTTP | 200 ✓ | 200 | — |
| Erreurs console | 0 ✓ | 0 | — |
| LCP | 1.8s ✓ | 1.6s | +200ms |
| CLS | 0.01 ✓ | 0.01 | — |
| API /health | 145ms ✓ | 120ms | +25ms |
| Actifs statiques | 42/42 ✓ | 42/42 | — |
| SSE /events | connecté ✓ | connecté | +80ms heartbeat |
### Aucune régression détectée. Le déploiement est propre.
Intégration
Associez à :
/browser-qapour la vérification pré-déploiement- Hooks : ajoutez comme hook PostToolUse sur
git pushpour une vérification automatique après les déploiements - CI : exécutez dans GitHub Actions après l'étape de déploiement