Canary

Canary

I'll watch your deployment after it goes live, polling for errors and regressions until health is confirmed or a problem surfaces. Inspired by gstack's canary skill.

Token Optimization

Expected range: 200–600 tokens per poll cycle, 50 tokens (healthy exit)

Patterns used: Bash for all checks, early exit (all green on first check), progressive disclosure (status line per cycle → details only on failure)

Early exit: If all checks pass on the first cycle, report "Deployment healthy — all checks green" and stop.

Step 1 — Identify What to Monitor

Infer from the project or accept explicit arguments:

# Check for common deployment indicators
ls -la .env .env.production docker-compose.yml Procfile 2>/dev/null

# Check for health endpoint conventions
grep -r "health\|ping\|status" --include="*.json" --include="*.yaml" -l 2>/dev/null | head -5

# Check for error log locations
ls -la logs/ /var/log/app.log 2>/dev/null

If no targets are auto-detected, ask:

• What URL or endpoint should I poll?
• Where are the application logs?
• What error patterns should I watch for?

Step 2 — Configure the Watch Loop

Defaults (override via arguments):

• Poll interval: 30 seconds
• Max duration: 10 minutes
• Error threshold: 2 consecutive failures = alert
• Success threshold: 3 consecutive passes = declare healthy

# Example: /canary --url https://api.example.com/health --interval 30 --duration 10m

Step 3 — Poll Loop

Each cycle runs these checks in order. Stop looping on first FAIL or when success threshold is reached.

Check A — HTTP Health Endpoint

# Poll the health/status endpoint
status=$(curl -s -o /dev/null -w "%{http_code}" --max-time 10 "$HEALTH_URL" 2>/dev/null)
echo "HTTP $status — $(date '+%H:%M:%S')"

Pass: 200–299 Warn: 3xx or slow response (>2s) Fail: 4xx, 5xx, timeout

Check B — Error Log Scan

# Scan for new errors since last cycle
tail -n 50 "$LOG_FILE" 2>/dev/null | grep -iE "error|exception|fatal|panic|crash" | tail -5

Pass: No new errors Warn: Errors matching known non-critical patterns Fail: New unrecognized error or stack trace

Check C — Key Endpoint Smoke Test

# Hit one or two critical endpoints beyond the health check
for endpoint in "${CRITICAL_ENDPOINTS[@]}"; do
    code=$(curl -s -o /dev/null -w "%{http_code}" --max-time 10 "$endpoint")
    echo "  $endpoint → $code"
done

Check D — Error Rate (if metrics available)

# If a metrics endpoint is available (Prometheus, Datadog, etc.)
# Check error rate is below threshold

Step 4 — Report Each Cycle

Canary — cycle 3/20 — 14:32:05

  ✓ Health endpoint    200 (142ms)
  ✓ Error log          0 new errors
  ✓ /api/users         200
  ✓ /api/health        200

Status: WATCHING (3 consecutive passes — need 3 to declare healthy)

Step 5 — Terminal States

HEALTHY: Three consecutive all-pass cycles:

Canary — HEALTHY after 4 minutes

All checks passed 3× in a row. Deployment is confirmed healthy.

ALERT: Two consecutive failures on any check:

Canary — ALERT — cycle 6

  ✗ Health endpoint    503 (timeout)
  ✓ Error log          0 new errors

Action required: health endpoint is returning 503. Check logs and consider rollback.
Suggest: /deployment-rollback

TIMEOUT: Max duration reached without declaring healthy:

Canary — INCONCLUSIVE after 10 minutes

No failures detected, but success threshold not reached.
Recommend: extend monitoring or check manually.

Edge Cases

• No health endpoint: Fall back to checking error logs only; note the limitation
• Flaky endpoint (intermittent 5xx): Apply jitter to poll interval; require 2 consecutive failures to alert
• No log access: Skip log check; note it was skipped
• CI environment: Disable interactive output; write results to .claude/canary-results.json

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: manastalukdar
• Source: manastalukdar/ai-devstudio
• License: MIT

Install and usage instructions live in the source repository linked above.