Canary Watch — Post-Deploy Monitoring

When to Use

After deploying to production or staging
After merging a risky PR
When you want to verify a fix actually fixed it
Continuous monitoring during a launch window
After dependency upgrades

How It Works

Monitors a deployed URL for regressions. Runs in a loop until stopped or until the watch window expires.

What It Watches

1. HTTP Status — is the page returning 200?
2. Console Errors — new errors that weren't there before?
3. Network Failures — failed API calls, 5xx responses?
4. Performance — LCP/CLS/INP regression vs baseline?
5. Content — did key elements disappear? (h1, nav, footer, CTA)
6. API Health — are critical endpoints responding within SLA?

Watch Modes

Quick check (default): single pass, report results

/canary-watch https://myapp.com

Sustained watch: check every N minutes for M hours

/canary-watch https://myapp.com --interval 5m --duration 2h

Diff mode: compare staging vs production

/canary-watch --compare https://staging.myapp.com https://myapp.com

Alert Thresholds

critical:  # immediate alert
  - HTTP status != 200
  - Console error count > 5 (new errors only)
  - LCP > 4s
  - API endpoint returns 5xx

warning:   # flag in report
  - LCP increased > 500ms from baseline
  - CLS > 0.1
  - New console warnings
  - Response time > 2x baseline

info:      # log only
  - Minor performance variance
  - New network requests (third-party scripts added?)

Notifications

When a critical threshold is crossed:

Desktop notification (macOS/Linux)
Optional: Slack/Discord webhook
Log to ~/.claude/canary-watch.log

Output

## Canary Report — myapp.com — 2026-03-23 03:15 PST

### Status: HEALTHY ✓

| Check | Result | Baseline | Delta |
|-------|--------|----------|-------|
| HTTP | 200 ✓ | 200 | — |
| Console errors | 0 ✓ | 0 | — |
| LCP | 1.8s ✓ | 1.6s | +200ms |
| CLS | 0.01 ✓ | 0.01 | — |
| API /health | 145ms ✓ | 120ms | +25ms |

### No regressions detected. Deploy is clean.

Integration

Pair with:

/browser-qa for pre-deploy verification
Hooks: add as a PostToolUse hook on git push to auto-check after deploys
CI: run in GitHub Actions after deploy step

Files1

1 files · 1.0 KB

Select a file to preview

Overall Score

76/100

Grade

B

Good

Safety

78

Quality

72

Clarity

85

Completeness

65

Summary

Canary Watch monitors a deployed URL for regressions after deploys, merges, or dependency upgrades by checking HTTP status, console errors, network failures, performance metrics, content integrity, and API health. It supports single-pass quick checks, sustained monitoring loops, and staging-vs-production diff mode, with configurable alert thresholds and desktop/Slack notifications.

Detected Capabilities

HTTP status monitoringConsole error detectionNetwork request inspectionCore Web Vitals tracking (LCP, CLS, INP)DOM content verificationAPI endpoint health checksPerformance baseline comparisonSustained monitoring loops with configurable intervalsDesktop and Slack notificationsStaging vs production diff modeLogging to user home directory

Trigger Keywords

Phrases that MCP clients use to match this skill to user intent.

post-deploy monitoringcanary checkregression detectionverify deploymentperformance baselinestaging comparison

Risk Signals

WARNING

Referenced external domains (myapp.com, staging.myapp.com) without validation or allowlist

Skill usage examples

WARNING

Optional Slack/Discord webhook integration mentioned without documented security guidance

Notifications section

INFO

Logging to ~/.claude/canary-watch.log may expose timing information or URLs in plaintext logs

Notifications section

INFO

No documented validation or rate-limiting for sustained monitoring loops

Watch Modes section

Referenced Domains

External domains referenced in skill content, detected by static analysis.

myapp.comstaging.myapp.com

Use Cases

Monitor production after deployment to catch immediate regressions
Verify staging changes before merging risky PRs
Track performance metrics during launch windows
Validate dependency upgrade safety
Compare staging and production behavior

Quality Notes

Clear, well-structured documentation with distinct sections for use cases, watch modes, and thresholds
Excellent use of tables and code blocks to show alert thresholds and output format
Concrete examples provided for all three watch modes (quick, sustained, diff)
Alert thresholds are quantified and actionable (e.g., LCP > 4s, CLS > 0.1)
Missing implementation details: no guidance on how baseline metrics are established or stored
No documented error handling for network timeouts, unreachable URLs, or invalid domains
Edge cases not addressed: what happens if URL returns 3xx redirects? How are dynamic content changes detected?
No mention of how console errors are distinguished from browser-native warnings (third-party ads, polyfills, etc.)
Integration section mentions PostToolUse hooks but doesn't specify exact hook syntax or configuration
Webhook integration mentioned but no security guidance on token storage or HTTPS enforcement

Model: claude-haiku-4-5-20251001Analyzed: Apr 20, 2026

Reviews

Add this skill to your library to leave a review.

No reviews yet

Be the first to share your experience.

Version History

v1.1

Content updated

2026-04-20

Latest

v1.0

No changelog

2026-04-12

canary-watch