Vendor Change Watchdog

Monitor vendor policy, pricing, and support changes before they surprise your team.

Guide

User Guide

How to use Vendor Change Watchdog effectively and what to expect from its alerts.

Vendor Change Watchdog User Guide

What This Tool Is For

Vendor Change Watchdog helps you notice when an important vendor page changes in a way that may affect your business.

Examples:

  • a privacy policy changes how customer data may be used
  • a pricing page changes plan cost or support level
  • a terms page changes vendor rights or customer obligations
  • an API docs page changes availability, limits, or feature commitments

The app is meant to save review time, not replace human judgment.

What You See In The App

Monitored pages

These are the vendor pages you are tracking.

Each page shows:

  • vendor name
  • URL
  • page type
  • next scheduled check
  • last checked time
  • last successful fetch
  • last error, if the page could not be fetched

You can also remove a monitored page from the dashboard list or from the page detail screen when you no longer want that vendor page checked.

The page detail screen also includes quick actions for common page-management changes:

  • set the cadence to 15m, 60m, or daily
  • mute alerts
  • switch the page to high severity only
  • restore the page back to the account default alert behavior

Use the full schedule and notification forms below those quick actions when you need a custom cadence, custom destination email, or a different severity threshold.

The dashboard monitored-pages section also supports bulk actions across selected pages:

  • run checks on the selected pages
  • turn alerts on or off
  • set the minimum alert severity
  • set or clear a page-group tag
  • remove the selected pages

Select the pages first in the monitored-pages panel, then apply the bulk action from the shared control bar above the list.

You can also assign a short page-group tag such as privacy, payments, or high risk.

Page-group tags appear on monitored-page cards, can be edited from the page detail screen, and can be used as a dashboard filter so you can focus on one subset of monitored pages at a time.

The dashboard also now makes page-level alert tuning visible without opening each page:

  • whether alerts are muted
  • whether a page is high severity only
  • whether a page uses a custom alert email
  • whether a page is still using the account default alert behavior

Candidate validation

Before creating a new monitored page, use Validate candidate on the dashboard.

This checks the real fetch/extract path without saving anything yet.

On success, the app shows:

  • HTTP status
  • normalized content length
  • a short content-hash prefix
  • a short extracted-text preview

On failure, the app shows the fetch error directly.

Use this to avoid adding pages that the current fetcher cannot monitor reliably.

Curated vendor pages and starter bundles

The dashboard also includes a curated catalog of known-good pages that have already been validated for the current fetcher.

You can use it in two ways:

  • add a single curated page to your account
  • add a starter bundle that creates a small watchlist in one step

The curated catalog supports:

  • text search
  • category filters
  • bundle filters

Starter bundles are useful when you want a fast baseline without researching URLs manually.

Current examples include:

  • Privacy Baseline
  • GitHub Copilot Watchlist
  • AI Coding Tools
  • Recent Policy Announcements
  • Payments Watchlist

For a brand-new account, the dashboard now also shows a first-run setup panel that points you toward starter bundles, curated pages, manual entry, and the guide before you have any monitored pages.

Plans and limits

New self-serve accounts start on the free plan.

Current free plan behavior:

  • up to 3 monitored pages
  • usage is shown in the dashboard add-page panel
  • trying to create a fourth page returns a clear limit message instead of saving the page

Internal or manually provisioned accounts may use other plans, such as beta.

Beta feedback

Beta-plan users now have an in-app feedback form on the account page.

Use it to report:

  • bugs
  • confusing flows
  • noisy or misleading alerts
  • feature requests

Each submission goes to an admin review queue inside the app, so the operator can triage tester feedback without relying on email threads.

Changes

A change record is created when the app thinks a new snapshot differs enough from the previous one to be worth analysis.

Each change record includes:

  • severity
  • categories
  • summary
  • notable points
  • evidence
  • previous and new snapshot text
  • review status
  • follow-up state
  • optional internal note

The dashboard recent-changes list also includes quick actions for common triage work:

  • mark a change as reviewed
  • mark a change as ignored
  • escalate a change
  • open or close follow-up without leaving the dashboard

Use the full change detail page when you need to edit the internal note or inspect the evidence and full snapshots.

Change workflow

On the change detail page, you can manage the review workflow for a detected change.

Current workflow fields:

  • review status:
    • new
    • reviewed
    • ignored
    • escalated
  • follow-up state:
    • none
    • open
    • closed
  • internal note:
    • freeform reviewer notes, next steps, or owner context

This is useful when a change needs human follow-up even after the initial review decision is clear.

Notifications

Notifications are email delivery attempts tied to a change.

Statuses:

  • sent: the email provider accepted the message
  • skipped: the app chose not to send or email delivery is not configured
  • failed: the send attempt errored
  • pending: send attempt has been created but not yet completed

Account settings

Use Account in the top navigation to manage your login and default alert identity.

From /account you can:

  • change your account email
  • change your password
  • review your current plan and monitored-page usage
  • see how many pages use custom alert-email overrides
  • see how many pages or notifications currently need attention
  • set default alert behavior for new pages
  • optionally apply the same alert defaults to your existing pages

The account email is also the default alert destination for pages that do not use a page-specific override.

What Severity Means

Severity is an estimate of likely practical impact.

Low

Likely minor wording or disclosure changes with limited practical impact.

Medium

Changes that are worth review because they may affect obligations, disclosures, or operational details.

High

Changes that may reduce protections, expand vendor rights, increase cost, or remove meaningful commitments.

Critical

Changes that likely deserve immediate human review because they may have material legal, commercial, or operational impact.

What Categories Mean

Categories are labels the app attaches to the detected change.

Examples:

  • pricing
  • support
  • sla
  • data_sharing
  • data_retention
  • data_usage
  • ai_training
  • feature_removal
  • compliance

These labels help you triage quickly. They are not a substitute for reading the evidence.

How To Review A Change

Use this order:

  1. Read the summary.
  2. Check the severity and categories.
  3. Read the evidence excerpts.
  4. Compare the Previous Snapshot and New Snapshot sections.
  5. Set the review status and follow-up state.
  6. Save an internal note if the change needs owner context or a next step.
  7. Decide whether the change matters for your team, contract, policy, or budget.

If the change looks important:

  • save the link to the change record
  • notify the relevant owner
  • review the vendor’s live page directly
  • make a human decision about response or escalation

What To Trust

Trust the tool for:

  • noticing that something changed
  • surfacing likely-important areas
  • giving you a faster review starting point

Trust humans for:

  • deciding whether the change is actually material
  • interpreting legal meaning
  • deciding whether a vendor action is acceptable
  • deciding whether to escalate internally

What Not To Assume

Do not assume:

  • every detected change is important
  • every important change will be perfectly classified
  • severity is legally authoritative
  • summaries are complete
  • lack of an alert means a vendor page is unchanged forever

Reasons:

  • some sites block or rate-limit fetches
  • some wording changes are ambiguous
  • extraction can miss or over-include text
  • model or heuristic analysis can misclassify context
  • a simple URL that looks reachable in a browser or HEAD request can still fail the real fetch path

Common Review Pattern

When you receive or see an alert:

  1. Confirm the page was fetched successfully.
  2. Read the summary and categories.
  3. Open the change detail page.
  4. Read the evidence.
  5. Scan the old/new snapshot text around the changed section.
  6. Decide whether to:
    • ignore
    • note for later
    • share with a stakeholder
    • escalate immediately

Notification Settings

Each monitored page can control:

  • how often the page is checked
  • whether notifications are enabled
  • which email address receives alerts
  • the minimum severity required before sending

Important behavior:

  • if the page-specific notification email is blank, alerts go to the account email
  • if you set a page-specific notification email, that page uses the override instead
  • new pages use the account email as their default alert destination unless you later add an override
  • new pages also inherit your account-level default alert on/off setting and minimum severity
  • you can update those defaults from /account and optionally push them to your existing monitored pages in one action

This helps reduce noise if some pages are useful for passive monitoring but do not need immediate alerts.

Current Limitations

This is still an early system.

Important limitations:

  • no password reset-by-email flow
  • no team workflow
  • no digest/suppression policy beyond per-page severity threshold
  • some vendor sites may block automated fetches
  • JavaScript-heavy pages may not be fully supported
  • email delivery depends on external provider setup

Recommended Operator Behavior

  • use the tool as an early warning system
  • review evidence before acting
  • keep monitored pages focused on high-value vendor pages
  • validate a new candidate before saving it
  • avoid monitoring too many low-signal pages
  • tune notification thresholds to reduce noise

The tool is most useful when it narrows attention to the right places quickly.