cfn-canary
MUST BE USED within 10 minutes of any production deployment. Post-deploy health monitoring. Polls a URL for 10 minutes checking for errors, performance regressions, and availability.
Best use case
cfn-canary is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
MUST BE USED within 10 minutes of any production deployment. Post-deploy health monitoring. Polls a URL for 10 minutes checking for errors, performance regressions, and availability.
Teams using cfn-canary should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/cfn-canary/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How cfn-canary Compares
| Feature / Agent | cfn-canary | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
MUST BE USED within 10 minutes of any production deployment. Post-deploy health monitoring. Polls a URL for 10 minutes checking for errors, performance regressions, and availability.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# CFN Canary **Purpose:** Monitor a deployed application for 10 minutes after deployment, detecting errors and regressions before users are affected. ## Usage Invoke as `/canary <url>` where url is the production endpoint to monitor. ## Monitoring Protocol ### Phase 1: Baseline Capture Before monitoring begins, capture baseline metrics: - HTTP status code - Response time (ms) - Response body size - Key response headers (content-type, cache-control) If no baseline exists, the first check becomes the baseline. ### Phase 2: Polling Loop (10 minutes, 30-second intervals) Every 30 seconds, check: 1. **Availability:** HTTP status 200? If not, alert. 2. **Response time:** >2x baseline? Flag as performance regression. 3. **Response size:** Changed significantly (>50% diff)? Flag as content change. 4. **Error indicators:** Check response body for common error patterns (500, "Internal Server Error", "503", stack traces). ### Phase 3: Alert Logic Transient tolerance: require 2+ consecutive failures before alerting. Single failures may be network blips. Alert levels: - **CRITICAL:** Site down (non-200 status, 2+ consecutive) - **WARNING:** Performance regression (response time >2x baseline, 2+ consecutive) - **INFO:** Content change detected (response size shift) ### Phase 4: Report Output summary: ``` ## Canary: <url> (10min) ### Status: HEALTHY | DEGRADED | DOWN ### Checks: N/N passed ### Alerts: N ### Timeline HH:MM:SS - 200 (Xms) OK HH:MM:SS - 200 (Xms) OK HH:MM:SS - 500 (Xms) ALERT: Server error ... ### Recommendation <action based on findings> ``` ## Limitations - HTTP-only monitoring (no browser rendering, no JS execution) - For full browser-based canary testing, combine with cfn-e2e - Does not check specific page content or user flows ## Integration - Run after `fly deploy` or any deployment command - Uses curl for HTTP checks (no external dependencies) - Can be combined with cfn-e2e for deeper verification