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, ordaily - mute alerts
- switch the page to
highseverity 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
highseverity 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 BaselineGitHub Copilot WatchlistAI Coding ToolsRecent Policy AnnouncementsPayments 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
3monitored 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:
newreviewedignoredescalated- follow-up state:
noneopenclosed- 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 messageskipped: the app chose not to send or email delivery is not configuredfailed: the send attempt erroredpending: 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:
pricingsupportsladata_sharingdata_retentiondata_usageai_trainingfeature_removalcompliance
These labels help you triage quickly. They are not a substitute for reading the evidence.
How To Review A Change
Use this order:
- Read the summary.
- Check the severity and categories.
- Read the evidence excerpts.
- Compare the
Previous SnapshotandNew Snapshotsections. - Set the review status and follow-up state.
- Save an internal note if the change needs owner context or a next step.
- 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
HEADrequest can still fail the real fetch path
Common Review Pattern
When you receive or see an alert:
- Confirm the page was fetched successfully.
- Read the summary and categories.
- Open the change detail page.
- Read the evidence.
- Scan the old/new snapshot text around the changed section.
- 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
/accountand 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.