/skill

Canary Watch

Original skill by ECC. Used with clear credit under its open-source license.

When to Use

Use this skill:

• After a deploy to test or live sites
• After a risky pull request is merged
• After a bug fix
• After a package update
• During a launch
• When you need to compare test and live sites

What to Check

Check each URL for:

1. HTTP status: Expect 200, unless another code is set.
2. Page errors: Find new errors in the browser console.
3. Request errors: Find failed API calls, timeouts, and 5xx replies.
4. Speed: Check LCP, CLS, and INP when the browser can report them.
5. Page parts: Check that key items still exist, such as h1, nav, footer, and the main button.
6. API health: Check that key API routes reply on time.
7. TLS: Report an old, wrong, or failed HTTPS certificate.
8. Redirects: Report redirect loops and wrong final URLs.

Only read the site. Do not submit forms, change data, place orders, or sign users out.

Modes

Quick Check

Run one check. This is the default.

/canary-watch https://myapp.com

Timed Watch

Check every set number of minutes for a set time.

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

Stop when the time ends or the user stops the task.

Compare

Compare a test site with a live site.

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

Treat the second URL as the base site. Ignore known changes that the user lists.

Default Limits

critical:
  - expected HTTP status is not returned
  - more than 5 new console errors
  - LCP is over 4 seconds
  - a key API route returns 5xx
  - HTTPS fails
  - a required page part is missing

warning:
  - LCP is over 500 ms slower than the base
  - CLS is over 0.1
  - there is a new console warning
  - reply time is over 2 times slower than the base
  - the final URL is not the expected URL

info:
  - there is a small speed change
  - there is a new network request
  - a page part changed but is still present

Use limits given by the user when they differ from these defaults.

Rules for Safe Checks

• Use a clear timeout for every page and API check. Use 30 seconds by default.
• Retry a failed check two times. Wait 5 seconds between tries.
• Mark a fault as steady only if all three tries fail.
• Report rate limits such as 429. Do not keep retrying them.
• Follow up to five redirects. Stop and report a loop.
• Do not skip HTTPS errors.
• Do not guess when login is needed. Report the login block.
• Never print cookies, tokens, passwords, or private page data.
• Do not save page text unless the user asks.
• Do not use webhooks, tracking, analytics, or outside alert services.
• Keep all logs on the local machine.
• Stop if checks may cause harm or change site data.

Baselines and Page Changes

If no base data exists:

• Run one clean check.
• Save its values as the local base.
• Mark later changes against that base.
• Say that the base came from the first check.

For pages with changing text, ads, dates, or user data:

• Check page shape and key items.
• Ignore changing text unless exact text is required.
• Do not call a change a bug only because page text differs.

If LCP, CLS, or INP cannot be read, mark the value as not available. Do not treat it as zero.

Alerts and Logs

For a critical fault:

• Show a local desktop alert when the system allows it.
• Write a local log entry to ~/.claude/canary-watch.log.
• Include the URL, time, failed check, retry count, and last result.

If a desktop alert is not supported, keep watching and note this in the report.

Report Format

## Canary Report: myapp.com

Time: 2026-03-23 03:15 PST
Mode: Quick check
Result: PASS

### Checks

- PASS: HTTP 200
- PASS: No new console errors
- PASS: LCP was 1.8s
- PASS: Key page parts were found

### Changes From Base

- CLS: 0.08, down by 0.02
- Reply time: 245ms, up by 12ms
- Network: 42 requests, up by 3

### Notes

- Three new requests came from one new script.

Use PASS, WARN, FAIL, or BLOCKED for the main result.

Concrete Example

Request:

/canary-watch https://shop.example.com --interval 5m --duration 30m

Expected work:

1. Open the URL every five minutes.
2. Check HTTP, HTTPS, page errors, failed requests, speed, and key page parts.
3. Retry each failed check two times.
4. Log each result on the local machine.
5. Show a local alert for a steady critical fault.
6. Stop after 30 minutes.
7. Give one final report with the first fault, last fault, and total pass and fail counts.

Use With Other Skills

• Use /benchmark when a full speed test is needed.
• Use /browser-qa when a full user flow must be tested.
• In CI, return a failed result for critical faults and a passed result with notes for warnings.