Canary Watch — 部署後監控 是做什麼的？
使用時機
- 部署至生產或暫存環境後
- 合併高風險 PR 後
- 想驗證某項修復是否確實生效時
- 發布窗口期間的持續監控
- 依賴升級後
運作方式
監控已部署 URL 是否存在回歸問題。會持續循環執行，直到被停止或監控時段結束。
監控項目
1. HTTP 狀態 — 頁面是否回傳 200？
2. 主控台錯誤 — 是否出現先前沒有的新錯誤？
3. 網路失敗 — API 呼叫失敗、5xx 回應？
4. 效能 — LCP/CLS/INP 與基線相比是否有回歸？
5. 內容 — 關鍵元素是否消失？（h1、nav、footer、CTA）
6. API 健康度 — 關鍵端點是否在 SLA 內回應？
7. 靜態資源 — JS、CSS、圖片和字型請求是否回傳 2xx/3xx 且 Content-Type 符合預期？
8. SSE 串流 — 事件串流端點是否能夠連線並接收到初始事件或心跳？
監控模式
快速檢查（預設）：單次執行，報告結果
/canary-watch https://myapp.com
持續監控：每隔 N 分鐘檢查一次，持續 M 小時
/canary-watch https://myapp.com --interval 5m --duration 2h
差異模式：比較暫存與生產環境
/canary-watch --compare https://staging.myapp.com https://myapp.com
警示閾值
critical: # 立即警示
- HTTP 狀態不等於 200
- 主控台錯誤數量 > 5（僅計算新錯誤）
- LCP > 4s
- API 端點回傳 5xx
- 靜態資源回傳 4xx/5xx
- SSE 端點無法連線或在首次心跳前斷線
warning: # 在報告中標記
- LCP 較基線增加超過 500ms
- CLS > 0.1
- 新的主控台警告
- 回應時間超過基線的 2 倍
- 靜態資源的 Content-Type 出乎意料地改變
- SSE 心跳延遲超過基線的 2 倍
info: # 僅記錄
- 微小的效能變異
- 新的網路請求（是否新增了第三方腳本？）
通知方式
當觸發嚴重閾值時：
- 桌面通知（macOS/Linux）
- 可選：Slack/Discord Webhook
- 記錄至
~/.claude/canary-watch.log
輸出範例
## Canary 報告 — myapp.com — 2026-03-23 03:15 PST
### 狀態：健康 ✓
| 檢查項目 | 結果 | 基線 | 差異 |
|----------|------|------|------|
| HTTP | 200 ✓ | 200 | — |
| 主控台錯誤 | 0 ✓ | 0 | — |
| LCP | 1.8s ✓ | 1.6s | +200ms |
| CLS | 0.01 ✓ | 0.01 | — |
| API /health | 145ms ✓ | 120ms | +25ms |
| 靜態資源 | 42/42 ✓ | 42/42 | — |
| SSE /events | 已連線 ✓ | 已連線 | +80ms 心跳 |
### 未檢測到任何回歸問題。部署狀態乾淨。
整合方式
搭配使用：
/browser-qa進行部署前驗證- 鉤子：在
git push時加入 PostToolUse 鉤子，在部署後自動檢查 - CI：在 GitHub Actions 的部署步驟後執行此檢查