/canary

name: canary
description: Post-deploy canary monitoring — checks site health, detects regressions, monitors for errors after deployment. Use after deploying to verify production is healthy.
argument-hint: "<production-url>"
allowed-tools: Bash, Read, Grep

Post-Deploy Canary Monitor

After every deploy, canary monitoring verifies your production site is healthy. It checks HTTP status, response time, error patterns, and compares against a baseline to detect regressions.

**Announce at start:** "I'm running post-deploy canary monitoring."

Process

Step 1: Run Canary Checks

node ${CLAUDE_PLUGIN_ROOT}/tools/canary-monitor.mjs <production-url> --checks 3 --interval 2

This runs 3 health checks with 2-second intervals. Options:

• `--checks N` — number of checks to run (default: 3)
• `--interval S` — seconds between checks (default: 2)
• `--baseline <file>` — path to baseline file for regression comparison

Step 2: Analyze Results

The canary monitor returns a health status:

| Status | Meaning | Action | |---|---|---| | `healthy` | All checks pass, no regressions | Deploy succeeded | | `degraded` | Site is up but has error patterns or issues | Investigate the specific issues | | `regression_detected` | Performance or behavior regressed from baseline | Compare with baseline, consider rollback | | `critical_regression` | Major regression (status code change, 3x slower) | Rollback immediately | | `down` | Site is unreachable or returning errors | Rollback immediately, use `/rescue` |

Step 3: Report

Present the results clearly:

+===========================================+
|     C A N A R Y   R E P O R T            |
+===========================================+
|  URL           savemrr.co                 |
|  Status        ✓ HEALTHY                  |
|  Response Time 234ms (avg)                |
|  Checks        3/3 passed                 |
|  Regressions   None                       |
+===========================================+

If issues are found, show them with severity and recommended action.

Step 4: If Unhealthy

If the canary detects problems:

**If a Sentry MCP server is connected** (check your available tools for `sentry`), confirm the regression against live error data: compare the error/issue rate since this deploy to the prior baseline window. A post-deploy spike in a new issue is hard confirmation that the deploy caused it — and the stack trace tells you exactly what to roll back or fix. Distinguish a real regression from background noise this way before recommending a rollback.

1. **`degraded`** — Show the specific error patterns found. Check if they're pre-existing or new. 2. **`regression_detected`** — Show the before/after comparison. If response time regressed >50%, investigate. 3. **`critical_regression` or `down`** — Recommend immediate rollback:

   git revert HEAD --no-edit && git push

Then use `/rescue` for full incident diagnosis.

Step 5: Save Baseline

When the site is healthy, the canary automatically saves a baseline to `.ultraship/canary/baseline.json`. Future canary runs compare against this baseline to detect regressions.

Continuous Monitoring Loop

For extended monitoring after a risky deploy:

node ${CLAUDE_PLUGIN_ROOT}/tools/canary-monitor.mjs <url> --checks 10 --interval 30

This runs 10 checks over 5 minutes, catching delayed failures (connection pool exhaustion, memory leaks, cache warm-up issues).

Integration with Other Skills

• **`/deploy`** — Run canary automatically after deploy completes
• **`/rescue`** — If canary detects `down` or `critical_regression`, escalate to incident response
• **`/retro`** — Include canary results in sprint retrospectives
• **`/learn`** — Save deployment gotchas as learnings when canary catches issues

Playwright Browser Checks (Optional)

For deeper verification, combine canary with Playwright MCP:

1. Navigate to the production URL 2. Take a screenshot 3. Check for console errors via `browser_console_messages` 4. Verify key user flows (login, main feature) work 5. Compare screenshots with pre-deploy captures (via `/visual-diff`)

This catches JavaScript errors, broken layouts, and functional regressions that HTTP-only checks miss.