Monitoring

Monitoring in this repo is broader than scheduled Playwright suites. Some risks are better caught by focused monitors than by full regression runs. The job of a monitor is not to prove the whole site works. It is to catch a narrow class of breakage early and cheaply.

Monitoring Versus Testing

Current Monitors

Consent Monitor

The consent monitor exists because consent breakage can make many unrelated tests look broken.

Main command: npm run monitor:consent

Selector Monitor

The selector monitor is a lightweight “are our assumptions still true?” check for important surfaces.

Main command: npm run monitor:selectors

robots.txt And Sitemap Monitor

This is one of the most useful narrow monitors in the repo because it watches a high-stakes surface that product teams can change without obviously breaking the homepage.

Current operating model:

• daily check
• all 16 CNC sites
• deduplicated alerting
• stored state for change detection

%%{init: {'theme':'base', 'themeVariables': {'primaryColor': '#4a90d9', 'primaryTextColor': '#fff', 'primaryBorderColor': '#2c6fad', 'lineColor': '#555', 'fontFamily': 'sans-serif'}}}%%
flowchart TD
    S["For each of 16 sites"] --> A["Fetch robots.txt"]
    A --> B["SHA-256 hash"]
    B --> C{Changed?}
    C -- Yes --> D["Slack alert\nwith line diff\n@Martin"]
    C -- No --> E["Update lastChecked"]

    A --> F["Parse Sitemap: lines\n(auto-discovered)"]
    F --> G["Fetch each sitemapindex\n(GET)"]
    G --> H["Extract nested loc URLs"]
    H --> I["Check all URLs\nconcurrently"]
    I --> J{Any non-200?}
    J -- Yes --> K["Deduplicate\n(7-day window)"]
    K --> L["Slack alert\nfor new failures\n@Martin"]
    J -- No --> M["All OK — silent"]

Main command: npm run monitor:robots-txt

URL Monitor

The URL monitor is the link-quality system. It crawls, classifies, deduplicates, and reports broken or risky links.

Main commands:

Grafana Visual Monitor

This monitor checks dashboards in a browser instead of trusting API-level health alone.

Main commands:

How To Think About Frequency

Good Operational Practice

• use focused monitors to catch narrow but expensive problems early
• do not expect a single monitor to replace a full suite
• route monitor alerts differently from regression alerts when the urgency differs
• prefer one well-clustered alert over many noisy duplicates

One practical pattern looks like this:

1. monitors catch drift early
2. Slack posts a low-noise alert
3. operator checks whether the issue is isolated or broad
4. if needed, a deeper suite runs to confirm user impact

Related Pages