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.