Canary Watch — Surveillance Post-Déploiement
Quand l'utiliser
- Après un déploiement en production ou staging
- Après avoir fusionné 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 retourne-t-elle 200 ?
2. Erreurs de console — de nouvelles erreurs qui n'existaient pas avant ?
3. Échecs réseau — appels API échoués, réponses 5xx ?
4. Performance — 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é API — les points de terminaison critiques répondent-ils dans les SLA ?
7. Actifs statiques — les requêtes JS, CSS, image et police retournent-elles 2xx/3xx avec les types de contenu attendus ?
8. Flux SSE — les points de terminaison de flux d'événements 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, rapporter les résultats
/canary-watch https://myapp.com
Surveillance continue : vérifier toutes les N minutes pendant M heures
/canary-watch https://myapp.com --interval 5m --duration 2h
Mode comparaison : comparer 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
- Point de terminaison API retourne 5xx
- Actif statique retourne 4xx/5xx
- Point de terminaison SSE ne peut pas se connecter ou se déconnecte avant le premier heartbeat
warning: # signaler 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: # journal uniquement
- Variation de performance mineure
- Nouvelles requêtes réseau (scripts tiers ajoutés ?)
Notifications
Lorsqu'un seuil critique est franchi :
- Notification bureau (macOS/Linux)
- Optionnel : webhook Slack/Discord
- Journal 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 | Delta |
|--------------|----------|-----------|-------|
| 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
Associer avec :
/browser-qapour la vérification pré-déploiement- Hooks : ajouter comme un hook PostToolUse sur
git pushpour vérifier automatiquement après les déploiements - CI : exécuter dans GitHub Actions après l'étape de déploiement