canary

Monitors deployed web apps for console errors, performance regressions, and page failures using browser screenshots.

Updated Apr 5, 2026
One-click install
npx skills add https://github.com/VertaKhan/cs_gstack --skill canary-vertakhan
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: canary
Source: https://github.com/VertaKhan/cs_gstack/tree/main/.claude/skills/gstack/canary
Command: npx skills add https://github.com/VertaKhan/cs_gstack --skill canary-vertakhan

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Deploys that pass CI can still break in production due to missing environment variables, stale CDN caches, or slow migrations. This Skill watches the live app in the first minutes after a deploy and catches regressions before users report them. ## Core Features & Use Cases - Baseline Capture: Take pre-deploy screenshots, console error counts, and load times per page, then compare post-deploy state against them. - Continuous Monitoring Loop: Check pages every 60 seconds for a configurable duration (1-30 minutes), alerting only on changes that persist across consecutive checks. - Severity-Based Alerts: Classify findings as CRITICAL (page load failure), HIGH (new console errors), MEDIUM (2x load time regression), or LOW (new broken links), each with screenshot evidence. - Use Case: After shipping a release, run the canary against your production URL for 10 minutes. It auto-discovers navigation pages, watches them, and produces a health report with a HEALTHY, DEGRADED, or BROKEN verdict. ## Quick Start Ask the AI to run /canary against your production URL to monitor the deploy for 10 minutes and report any console errors or performance regressions.

Frequently Asked Questions about canary

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I monitor a website after deployment for errors?▼

Run /canary with your production URL to start a 10-minute monitoring loop. It checks pages every 60 seconds for new console errors, load failures, and performance regressions, alerting only on issues that persist across consecutive checks.

How to capture baseline screenshots before deploying a web app?▼

Run /canary with the --baseline flag before deploying. It saves screenshots, console error counts, and page load times to a baseline.json manifest, which later monitoring runs use as the comparison reference.

Can I monitor specific pages instead of the whole site?▼

Yes, pass --pages with a comma-separated list like /,/dashboard,/settings. Without it, the skill auto-discovers the top 5 internal navigation links and asks you to confirm which pages to watch.

What triggers a canary alert during post-deploy monitoring?▼

Alerts fire on changes relative to baseline: page load failures are CRITICAL, new console errors are HIGH, load times exceeding 2x baseline are MEDIUM, and new 404s are LOW. Single transient blips are ignored until they persist across 2 or more checks.

What are the limitations of screenshot-based deploy monitoring?▼

It is read-only and observational, so it detects symptoms but does not fix code. Without a pre-deploy baseline it acts as a simple health check, and it requires the gstack browse daemon to be built before first use.