Canary Watch
Smoke-test a live URL after deploy with HTTP, assets, SSE, console, and performance checks in quick or sustained watch modes.
Overview
Canary Watch is an agent skill most often used in Operate (also Ship and Launch) that monitors a deployed URL for HTTP, asset, SSE, console, and performance regressions after releases.
Install
npx skills add https://github.com/affaan-m/everything-claude-code --skill canary-watchWhat is this skill?
- Watches HTTP status, console errors, network failures, LCP/CLS/INP vs baseline, and critical DOM elements
- Checks static assets (JS, CSS, fonts) for 2xx/3xx and expected content types
- Verifies SSE/event-stream endpoints connect and receive heartbeat or initial events
- Quick single pass or sustained loop with --interval and --duration for launch windows
- Diff mode compares current behavior against a saved baseline after risky merges or dependency upgrades
- 8 watch dimensions including HTTP, console, network, performance, content, API health, static assets, and SSE
Adoption & trust: 3.4k installs on skills.sh; 210k GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You shipped to staging or production and do not know if the deploy broke APIs, assets, streams, or UX metrics until users report it.
Who is it for?
Solo builders running frequent deploys who want automated smoke and canary checks on a known URL without building custom scripts each time.
Skip if: Local-only development with no deployed endpoint, or teams that already own full APM/synthetic suites and only need log correlation inside the cluster.
When should I use this skill?
After deploying to production or staging, after merging a risky PR, when verifying a fix, during a launch window, or after dependency upgrades.
What do I get? / Deliverables
You get a structured pass/fail report from a quick or sustained watch—and optional diff vs baseline—so you can roll back or confirm the fix before traffic fully hits the change.
- Canary watch report
- Regression diff vs baseline when enabled
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Operate because the skill’s value is keeping production healthy after something is already live. It performs active URL monitoring and regression detection—the monitoring subphase—not infra provisioning or error triage alone.
Where it fits
Run a quick /canary-watch on staging right before promoting the same build to production.
Sustain watches every five minutes for two hours during a Product Hunt or email blast launch window.
Diff mode after a dependency upgrade to see new console errors or missing nav/footer CTAs.
Re-run the watch after a hotfix to confirm API health endpoints and static assets recovered.
How it compares
Post-deploy browser and HTTP verification workflow—not a unit-test skill or a long-term infra monitoring stack installer.
Common Questions / FAQ
Who is canary-watch for?
Indie and solo builders using Claude Code–style agents who deploy web apps and need fast confirmation that production or staging still works end to end.
When should I use canary-watch?
After Ship when a build hits staging or prod, during Launch for sustained launch-window checks, and in Operate after dependency upgrades or when verifying a hotfix actually fixed user-visible errors.
Is canary-watch safe to install?
It implies hitting live URLs and possibly browser automation; review Security Audits on this page and scope network/browser permissions to URLs you control.
SKILL.md
READMESKILL.md - Canary Watch
# 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 ```yaml 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 ```markdown ## 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-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