canary-watch
affaan-m/everything-claude-code
Monitor deployed URLs for regressions—checks endpoints, assets, performance, and console errors after releases.
What is canary-watch?
Canary Watch verifies a deployed application by monitoring HTTP status, console errors, performance metrics, static assets, API health, and SSE streams. Use it immediately after deployments, merges, or dependency upgrades to catch regressions before users do.
- Monitor HTTP status codes and response health
- Detect new console errors and warnings in real time
- Track Core Web Vitals (LCP, CLS, INP) against baseline
- Verify static assets (JS, CSS, images, fonts) load with correct content types
- Check critical API endpoints for 5xx errors and SLA compliance
- Monitor Server-Sent Events (SSE) streams for connectivity and heartbeat latency
How to install canary-watch
npx skills add https://github.com/affaan-m/everything-claude-code --skill canary-watchHow to use canary-watch
- 1.Run a quick single-pass check: `/canary-watch https://myapp.com`
- 2.For sustained monitoring, specify interval and duration: `/canary-watch https://myapp.com --interval 5m --duration 2h`
- 3.To compare two environments: `/canary-watch --compare https://staging.myapp.com https://myapp.com`
- 4.Review the generated canary report for status, metrics, and any regressions detected
- 5.Check `~/.claude/canary-watch.log` for detailed logs and historical records
Use cases
- Verify a production deployment is healthy immediately after release
- Monitor a staging environment during a risky PR merge
- Track performance metrics during a launch window to catch regressions early
- Compare staging and production to identify environment-specific issues
- Detect new console errors introduced by a dependency upgrade
- DevOps engineers managing post-deploy verification
- Frontend engineers verifying releases before announcing to users
- QA teams running smoke tests after deployments
- Platform teams automating canary checks in CI/CD pipelines
- On-call engineers responding to deploy incidents
canary-watch FAQ
HTTP status not 200, more than 5 new console errors, LCP > 4s, API endpoints returning 5xx, static assets returning 4xx/5xx, or SSE endpoints failing to connect or dropping before first heartbeat.
It compares current metrics against a stored baseline from the previous healthy deployment. You can also use `--compare` mode to directly compare staging vs production.
Yes. Add it as a PostToolUse hook on `git push` to auto-check after deploys, or run it as a step in GitHub Actions after your deploy step completes.
You receive a desktop notification, an optional Slack/Discord webhook alert, and a detailed log entry in `~/.claude/canary-watch.log`.
Yes. It monitors all network requests and flags unexpected new third-party scripts or content type changes in static assets as warnings.
Full instructions (SKILL.md)
Source of truth, from affaan-m/everything-claude-code.
name: canary-watch description: Use this skill to monitor and verify a deployed URL after releases — checks HTTP endpoints, SSE streams, static assets, console errors, and performance regressions after deploys, merges, or dependency upgrades. Smoke / canary / post-deploy verification. metadata: origin: ECC
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?
7. Static Assets — are JS, CSS, image, and font requests returning 2xx/3xx with expected content types?
8. SSE Streams — do event-stream endpoints connect and receive an initial event or heartbeat?
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
- Static asset returns 4xx/5xx
- SSE endpoint cannot connect or drops before first heartbeat
warning: # flag in report
- LCP increased > 500ms from baseline
- CLS > 0.1
- New console warnings
- Response time > 2x baseline
- Static asset content type changed unexpectedly
- SSE heartbeat latency > 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 |
| Static assets | 42/42 ✓ | 42/42 | — |
| SSE /events | connected ✓ | connected | +80ms heartbeat |
### No regressions detected. Deploy is clean.
Integration
Pair with:
/browser-qafor pre-deploy verification- Hooks: add as a PostToolUse hook on
git pushto auto-check after deploys - CI: run in GitHub Actions after deploy step
Related skills
More from affaan-m/everything-claude-code and the wider catalog.
security-review
Security checklist and patterns for authentication, input validation, secrets, and sensitive features.
golang-patterns
Idiomatic Go patterns, best practices, and conventions for building robust, efficient, and maintainable applications.
coding-standards
Baseline coding conventions for naming, readability, immutability, and quality across projects.
frontend-patterns
React and Next.js patterns for components, state management, performance, and modern frontend practices.
backend-patterns
REST/GraphQL API design, database optimization, and server-side patterns for Node.js, Express, and Next.js.
golang-testing
Go testing patterns: table-driven tests, subtests, benchmarks, fuzzing, and TDD methodology.