monitoring-web-regressions

Detects web performance regressions by comparing latest test runs against historical medians.

Updated Apr 11, 2026
One-click install
npx skills add https://github.com/celikgo/webmobai --skill monitoring-web-regressions-celikgo
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: monitoring-web-regressions
Source: https://github.com/celikgo/webmobai/tree/main/.claude/skills/monitoring-web-regressions
Command: npx skills add https://github.com/celikgo/webmobai --skill monitoring-web-regressions-celikgo

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? It answers whether a URL is getting worse over time by reading WebMobAI's persisted run history and comparing the latest run against the median of prior runs, so you catch performance, accessibility, and console-error regressions instead of relying on one-off snapshots. ## Core Features & Use Cases - Run History Trends: Reads ~/.webmobai/history.json via webmobai_get_run_history to show LCP, CLS, FCP, pass rates, and error counts across past runs for a URL. - Regression Detection: Compares the latest run against a configurable median baseline using webmobai_check_regressions, tagging each of seven metrics as regression, improvement, or noise. - Continuous Monitoring Setup: Documents the webmobai-monitor binary for scheduled runs with webhook alerts, including its fixed ±10% threshold and its inability to handle authenticated pages. - Use Case: After a deploy, ask whether LCP regressed on your staging site; the skill checks the latest run against the median of the last five runs and reports the exact delta with a plain-language verdict. ## Quick Start Ask the AI to check whether https://example.com has regressed compared to its recent test history.

Frequently Asked Questions about monitoring-web-regressions

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

FAQPage Schema
How do I check if a website regressed after a deploy?▼

Run webmobai_check_regressions with the URL to compare the latest run against the median of up to five prior runs. It flags deviations in LCP, FCP, CLS, TTI, TTFB, console errors, and accessibility issues beyond a 10% threshold, which you can tighten with threshold_pct.

How to monitor a URL on a schedule with regression alerts?▼

Use the webmobai-monitor binary with an interval like --interval=10m and an --alert-webhook URL. It spawns webmobai-test each tick and POSTs a JSON regression bundle when any metric exceeds a fixed ±10% over a 5-run median.

Why does the regression check say not enough history?▼

The check needs at least two prior runs per exact URL, and three total runs for a meaningful verdict. History is keyed by the exact URL string, so trailing slashes or query strings create separate keys; list all history without a URL filter to see the stored keys.

Can I monitor a page behind a login with webmobai-monitor?▼

No, not reliably. webmobai-test has no storageState support, so the monitor only offers a legacy credentials heuristic that works on landing-page login forms and exposes credentials in process arguments. Monitor public URLs instead and gate authenticated pages via CI suites.

Does webmobai-monitor work on a headless CI runner?▼

No. webmobai-test hardcodes headless mode off, so the monitor requires a display server and will not run on a bare CI runner or SSH session. For per-deploy checks in CI, use an authenticated webmobai-suite pipeline instead.

What are the limitations of WebMobAI run history?▼

History is stored locally per machine at ~/.webmobai/history.json with a global 200-entry cap shared across all URLs, so monitoring several URLs frequently evicts old baselines. Only webmobai-test writes history; scenario and suite runs leave no trend data.