canary

Monitors live applications after deployment for console errors, performance regressions, and page failures.

Updated May 7, 2026
One-click install
npx skills add https://github.com/TumeloRamaphosa/StudEx-Valley-OS --skill canary-tumeloramaphosa
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: canary
Source: https://github.com/TumeloRamaphosa/StudEx-Valley-OS/tree/main/.claude/skills/gstack/canary
Command: npx skills add https://github.com/TumeloRamaphosa/StudEx-Valley-OS --skill canary-tumeloramaphosa

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill reduces the risk of a bad release by continuously watching the live app after deployment for production-breaking signals like console errors, slowdowns, and missing or failed pages.

Core Features & Use Cases

  • Post-deploy monitoring: Watches the live application for console errors, performance regressions, and page failures using the browse daemon.
  • Baseline-aware anomaly detection: Takes periodic screenshots and compares them against pre-deploy baselines to catch UI or routing regressions.
  • Operational workflow fit: Designed to run during “monitor deploy” and “post-deploy check” scenarios to quickly surface anomalies to the team.

Quick Start

Run canary to monitor the live app after your deploy, compare screenshots to the pre-deploy baseline, and alert on any detected anomalies.

Frequently Asked Questions about canary

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

FAQPage Schema
How do I monitor production health after a deploy to catch console errors?

Post-deploy monitoring verifies production health by watching the live application for console errors, performance regressions, and page failures using a browse daemon to surface anomalies immediately after a release.

What is canary deployment monitoring and when do I need it?

Canary deployment monitoring is the process of watching a live application for production-breaking signals after a release. You need it before assuming traffic is safe to quickly catch console errors, slowdowns, and page failures.

How do I detect UI regressions and page failures after a release?

You detect UI regressions by taking periodic screenshots after a release and comparing them against pre-deploy baselines. This screenshot diffing process catches visual anomalies, routing regressions, and page failures before traffic scales up.

Does post-deploy production monitoring work without external dependencies?

Yes, post-deploy production monitoring runs without external dependencies, relying solely on an internal browse daemon to perform periodic screenshot capture, baseline comparison, anomaly detection, and alerts for errors.

What is the best way to automate post-deploy checks for performance regressions?

The best way to automate post-deploy checks is using a browse daemon to continuously watch the live application, applying baseline-aware anomaly detection to compare screenshots and alert on performance regressions and page failures.

Why should I not route traffic immediately after a production deploy?

You should not route traffic immediately because production-breaking signals like console errors, slowdowns, and missing pages can occur. Post-deploy monitoring verifies deploy health and detects anomalies before assuming traffic is safe.