Menu
Post-deploy production monitoring — watches live app for errors, regressions, and failures after deployment
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Convert PDF/EPUB library to Markdown and generate Obsidian MOC notes
Hook-based compaction suggestions at logical task boundaries
Context window management — track spend, decide when to compact, preserve state
Session-start orientation — loads context, surfaces learnings, confirms registry
Quality and semantic review — catches what automated tools miss
Planner → Architect → Critic deliberation loop — produces a formally validated ADR
| name | canary |
| description | Post-deploy production monitoring — watches live app for errors, regressions, and failures after deployment |
| version | 0.1.0 |
| level | 2 |
| triggers | ["canary","watch production","post-deploy monitoring","/canary","monitor after deploy"] |
| context_files | ["context/project.md"] |
| steps | [{"name":"Baseline Load","description":"Load prior baseline if available; capture pre-monitoring snapshot if not"},{"name":"Page Discovery","description":"Use --pages list or monitor root URL and note limitation"},{"name":"Monitoring Loop","description":"Check each page every 60 seconds; alert only after 2 consecutive failures to suppress noise"},{"name":"Health Report","description":"Produce structured report with alerts, baseline deltas, and STABLE/DEGRADED/CRITICAL verdict"},{"name":"Baseline Update","description":"Offer to update baseline after a STABLE run"}] |
Post-deploy production monitoring. Run after deployment, not before. Watches live pages at 60-second intervals, filters out single-check noise, and surfaces only confirmed anomalies. Think of it as a canary in a coal mine: its job is to catch the signal before it becomes an incident.
Without a monitoring protocol, post-deploy checks are manual spot-checks: someone opens the app, clicks around, and declares it working. This misses intermittent failures, gradual degradation, and regression in non-primary routes.
The other failure mode is alert fatigue from a single failing check. A single 502 in a monitoring loop can be a transient infrastructure hiccup, not a deployment regression. Alerting on single failures trains people to ignore alerts. The two-consecutive-check rule separates signal from noise.
/canary <url> # Monitor for 10 minutes (default)
/canary <url> --baseline # Capture baseline before deploying
/canary <url> --duration 5m # Custom monitoring duration
/canary <url> --pages /,/dash,/login # Monitor specific routes
/canary <url> --quick # Single health check, no loop
If a baseline exists at context/canary/<url-slug>-baseline.json: load it as the comparison reference.
If --baseline is passed: capture current state as baseline and exit. Do not start the monitoring loop.
If no baseline and no --baseline flag: capture a pre-monitoring snapshot as the session reference. This is not a persistent baseline: it allows intra-session deltas to be reported.
Use the --pages list if provided. Otherwise monitor the root URL only and note: "Pass --pages to monitor additional routes." Do not guess which routes matter.
Check each page every 60 seconds for the specified duration. Per check:
curl -o /dev/null -s -w "%{http_code}|%{time_starttransfer}|%{time_total}" <url>
Alert levels:
| Level | Condition |
|---|---|
| CRITICAL | HTTP 5xx, timeout, or connection refused |
| HIGH | HTTP 4xx on a page that was previously 2xx |
| MEDIUM | TTFB more than 2x the baseline value |
| LOW | HTTP 404 on a resource that was previously reachable |
Alert only after the condition persists across 2 consecutive checks. A single failure is noise. Two in a row is signal.
On CRITICAL: surface immediately, do not wait for the duration to end.
## Canary Report: <url>
Duration monitored: [time]
Pages: [list]
Checks run: [count]
### Alerts
Level: CRITICAL | HIGH | MEDIUM | LOW
Page: [url]
Condition: [what was detected]
First seen: [timestamp]
Confirmed: YES (2+ checks) | UNCONFIRMED (1 check)
### Baseline deltas
[Metric] before: [value] / after: [value] / delta: [%]
### Verdict: STABLE | DEGRADED | CRITICAL
STABLE: no confirmed alerts, all metrics within baseline tolerance. DEGRADED: one or more MEDIUM or LOW confirmed alerts. CRITICAL: any CRITICAL or HIGH confirmed alert.
After a STABLE run, ask the user: "The deployment is stable. Do you want to update the baseline to the current measurements?"
Do not update the baseline automatically. Always ask.
Do not run canary before deployment. It monitors what is live, not what is staged.
Do not alert on single-check failures. Alert only after two consecutive failures on the same page.
Do not declare STABLE after a --quick single check. A single check detects a hard failure but cannot confirm stability over time.
Do not update the baseline without asking. A STABLE baseline is a deliberate record, not an automatic snapshot.