Canary: Post-Deploy Monitoring

Watch a live application after deployment. Alert on errors and regressions. Compare against a pre-deploy baseline.

Two modes:

• --baseline: capture the current state BEFORE deploying
• (default): monitor AFTER deploying and compare against baseline

Instructions

Phase 1: Setup

Parse the user's arguments and detect the deployment context.

# Detect current branch and recent deploy commit
git branch --show-current
git log --oneline -5

# Auto-detect platform from config files
[ -f fly.toml ]         && echo "PLATFORM: fly"
[ -f render.yaml ]      && echo "PLATFORM: render"
[ -f vercel.json ]      && echo "PLATFORM: vercel"
[ -f netlify.toml ]     && echo "PLATFORM: netlify"
[ -f Procfile ]         && echo "PLATFORM: heroku"
[ -f railway.toml ]     && echo "PLATFORM: railway"

# Check for health endpoint
curl -sf "${URL}/health" -w "\n%{http_code}" 2>/dev/null | tail -1
curl -sf "${URL}/api/health" -w "\n%{http_code}" 2>/dev/null | tail -1

Create the working directory:

mkdir -p .canary/baselines .canary/reports .canary/screenshots

Phase 2: Baseline Capture (--baseline mode)

Run this BEFORE deploying to capture the current healthy state.

For each page to monitor, record:

1. HTTP status: is the page returning 200?
2. Response time: how long does it take to load?
3. Content snapshot: key text content to detect blank pages later

# For each page URL
for PAGE_PATH in "/" "/dashboard" "/settings" "/api/health"; do
  SLUG=$(echo "$PAGE_PATH" | tr '/' '_' | tr -d '?&=')
  RESULT=$(curl -sf -o /dev/null -w "%{http_code}|%{time_total}" "${BASE_URL}${PAGE_PATH}" 2>/dev/null)
  STATUS=$(echo "$RESULT" | cut -d'|' -f1)
  TIME_MS=$(echo "$RESULT" | awk -F'|' '{printf "%.0f", $2 * 1000}')
  echo "  ${PAGE_PATH}: HTTP ${STATUS}, ${TIME_MS}ms"
done

Save baseline to .canary/baselines/baseline.json:

{
  "url": "<base-url>",
  "timestamp": "<ISO-8601>",
  "branch": "<branch-name>",
  "commit": "<git-SHA>",
  "pages": {
    "/": { "status": 200, "time_ms": 450 },
    "/dashboard": { "status": 200, "time_ms": 680 },
    "/api/health": { "status": 200, "time_ms": 45 }
  }
}

Then STOP and tell the user: "Baseline captured. Deploy your changes, then run /canary <url> to monitor."

Phase 3: Page Discovery

If no pages were specified, auto-discover pages to monitor.

From the application:

# Check sitemap if available
curl -sf "${URL}/sitemap.xml" 2>/dev/null | grep -oP '(?<=<loc>)[^<]+' | head -10

# Check robots.txt for known paths
curl -sf "${URL}/robots.txt" 2>/dev/null | grep -i "allow\|disallow" | head -10

# Common paths to always check
echo "Always check: / /login /dashboard /settings /api/health"

Default pages to monitor if nothing found: /, and the homepage only.

Phase 4: Monitoring Loop

Monitor for the specified duration (default: 10 minutes). Run a check every 60 seconds.

Each check cycle:

TIMESTAMP=$(date -u +%Y-%m-%dT%H:%M:%SZ)
CHECK_NUM=$((CHECK_NUM + 1))

for PAGE_PATH in "${PAGES[@]}"; do
  # Check HTTP status and response time
  RESULT=$(curl -sf -o /dev/null -w "%{http_code}|%{time_total}" \
    --max-time 10 "${BASE_URL}${PAGE_PATH}" 2>/dev/null || echo "0|0")
  STATUS=$(echo "$RESULT" | cut -d'|' -f1)
  TIME_MS=$(echo "$RESULT" | awk -F'|' '{printf "%.0f", $2 * 1000}')

  # Compare against baseline
  BASELINE_STATUS=$(jq -r ".pages[\"${PAGE_PATH}\"].status // 200" .canary/baselines/baseline.json 2>/dev/null)
  BASELINE_TIME=$(jq -r ".pages[\"${PAGE_PATH}\"].time_ms // 1000" .canary/baselines/baseline.json 2>/dev/null)

  echo "  [Check #${CHECK_NUM}] ${PAGE_PATH}: HTTP ${STATUS} (${TIME_MS}ms)"
done

Alert levels:

Key principles:

• Alert on changes, not absolutes. A page with 3 errors in baseline is fine if still 3. One NEW error is an alert.
• Transient tolerance. Only alert on patterns persisting across 2+ consecutive checks. A single network blip is not an alert.

When a CRITICAL or HIGH alert fires (2 consecutive checks):

CANARY ALERT
=====================================
Time:     [check #N at Xs elapsed]
Page:     [URL]
Level:    [CRITICAL / HIGH / MEDIUM / LOW]
Finding:  [what changed, be specific]
Baseline: [baseline value]
Current:  [current value]
=====================================
Options:
  A) Investigate now: stop monitoring, focus on this issue
  B) Continue monitoring: wait for next check to confirm
  C) Rollback: revert the deploy
  D) Dismiss: known issue, continue monitoring

Phase 5: Health Report

After monitoring completes (or user stops), produce a summary.

CANARY REPORT: [url]
=========================================
Duration:    [X minutes]
Checks:      [N total per page]
Pages:       [N pages monitored]
Commit:      [deployed SHA]
Status:      [HEALTHY / DEGRADED / BROKEN]

Per-Page Results:
-----------------------------------------
  Page           Status      Avg Time   Alerts
  /              HEALTHY     450ms      0
  /dashboard     DEGRADED    1100ms     1 medium (was 450ms)
  /settings      HEALTHY     380ms      0
  /api/health    HEALTHY     45ms       0

Alerts Fired: [N] (X critical, Y high, Z medium, W low)

VERDICT: [DEPLOY HEALTHY / DEPLOY HAS ISSUES (see alerts above)]
=========================================

Save report to .canary/reports/<date>-canary.md.

Phase 6: Baseline Update

If the deploy is healthy and the user wants to update the baseline:

cp .canary/reports/latest-snapshot.json .canary/baselines/baseline.json
echo "Baseline updated to commit $(git rev-parse --short HEAD)"

Output Format

See Phase 5 above for the full CANARY REPORT template.

Inline alert format (during monitoring):

[08:42:15] Check #3: /dashboard: ALERT HIGH, response time 1250ms (baseline: 420ms)
[08:43:15] Check #4: /dashboard: ALERT HIGH, response time 1180ms (baseline: 420ms)
-> Consistent across 2 checks. Firing alert.

Usage

/canary https://app.example.com                # Monitor homepage for 10 min
/canary https://app.example.com --baseline     # Capture baseline before deploying
/canary https://app.example.com --duration 5m  # Monitor for 5 minutes
/canary https://app.example.com --quick        # Single-pass health check (no loop)
/canary https://app.example.com --pages /,/dashboard,/api/health

Tips

1. Always capture a baseline before deploying to production: run /canary <url> --baseline
2. Start monitoring immediately after deploy; the first 5 minutes catch 90% of regressions
3. CRITICAL alerts require immediate investigation; don't wait for the monitoring to finish
4. MEDIUM alerts (performance) may be cache warming; give it 2-3 more checks before acting
5. Keep .canary/baselines/ in git so any team member can run canary against the same baseline

Related Commands

• /ship: pre-deploy checklist (run before deploying)
• /land-and-deploy: full merge-to-verify pipeline (runs canary automatically)
• /qa: interactive QA testing before shipping

$ARGUMENTS