1. Where the check runs
Three options: your browser, the vendor's cloud, or your own infrastructure. Browser extensions are the cheapest, but they stop when the browser closes, which is most of the time. Cloud services run 24/7 and are what most teams actually want. Self-hosted gives you control and costs you ops time. Pick the model that matches how you'll use the tool, not the lowest sticker price.
2. Minimum check interval at your tier
The single most consequential number on the pricing page, and the one most often buried. "Fast checks" can mean 60 seconds or it can mean 60 minutes depending on the tool and tier. Decide what your worst-case detection latency is. If a price change you didn't catch for 30 minutes would cost you sales, you need sub-minute checks and you need them at a price you'll actually pay. If you're monitoring a terms-of-service page, daily is fine.
Confirm during trial that the advertised interval is actually honored under load. Some tools advertise 5-minute checks but silently queue when their workers are saturated.
3. Element targeting
Monitoring an entire page rarely works in 2026. Cookie banners, personalization, A/B tests, dynamic ads, and rotating hero images will fire alerts every check cycle. You need to target the specific part of the page you care about. CSS selectors are table stakes; XPath is useful for trickier pages; a visual element picker is great for non-technical users.
The harder test: do the selectors hold up when the site rerenders? Some tools snapshot the DOM and your selector is brittle to any markup change; better tools normalize the content first.
4. JavaScript and SPA rendering
More than half the web is now JavaScript-rendered. If the tool still does a raw HTTP fetch and parses the HTML, it will miss anything rendered client-side, which is most modern apps. Confirm that the tool runs a real headless browser (Chromium or equivalent), waits for the page to be quiescent, and gives you control over wait conditions for slow APIs and lazy-loaded content.
5. API and JSON monitoring
If you're only monitoring web pages, skip this. If any of your monitors are JSON endpoints (REST APIs, GraphQL responses, internal status endpoints), you need a tool with a proper JSON diff view, not byte-level string comparison. The good ones let you write JSONPath expressions to target specific fields, ignore noisy timestamps, and detect schema-level changes (added or removed fields). Treat this as a first-class feature during evaluation, not a checkbox.
6. Alert routing
Alerts that land in email get ignored. Alerts that land in Slack, Discord, or PagerDuty get acted on. Check that every channel you care about is supported and, more importantly, that it's available on the tier you're considering, not gated three tiers up. Webhook support is also crucial for routing into internal systems (ticketing, on-call, custom dashboards).
One specific test: trigger a change and time how long it takes from detection to a message landing in your Slack channel. The difference between a 5-second pipeline and a 60-second pipeline shows up in incidents.
7. Alert content quality
"The page changed" is not useful. A good alert tells you what changed, where on the page, and in language a human can act on. The best tools include AI-generated change summaries ("the price increased from $49 to $59 on the Pro plan, the CTA text changed from 'Buy now' to 'Get started'") so you can triage from your phone.
8. Retention and history
How long does the tool keep diff history? 7 days is too short for almost anything; 90 days covers most operational use cases; indefinite retention is what you want for legal evidence. Match retention to your use case. Pay specifically for the requirement, not for what the vendor advertises.
9. REST API and automation
If you'll ever create more than 20 monitors, you'll want a REST API. If you ship in CI, you'll want one for sure (provision a monitor when a route ships; tear it down when the route is removed). The tools that treat the API as a first-class interface have clean docs, predictable resource shapes, and sensible auth. The tools that don't, don't.
Spend 15 minutes reading the API reference during evaluation. If you can't tell how to create a monitor from the docs alone, assume your engineers won't be able to either.
10. Pricing model honesty
Two anti-patterns to watch for. Feature gating: Slack on Business, webhooks on Pro, API on Enterprise. By the time you assemble the feature set you actually need, the price is 4x sticker. Frequency gating: the entry tier looks affordable but caps checks at 60 minutes; you upgrade to get 5-minute checks and the bill jumps. Compare per-monitor cost at the check frequency and feature set you actually need, not the headline number.
Red flags during evaluation
- -Pricing is "contact us" for anything other than enterprise add-ons.
- -Free trial requires a credit card or a demo call.
- -No public REST API documentation.
- -Status page is missing, hidden, or chronically green despite recent issues.
- -Changelog hasn't been updated in 6+ months.
- -Slack and webhook support is paywalled above the tier you were planning to buy.
The one-week trial template
The fastest way to cut through marketing copy is a structured trial. Pick two finalists. Spin up the same five monitors in both: one visual diff, one selector-targeted text diff, one JSON API, one low-frequency text diff, and one element you expect to change frequently (to test false-positive resistance). Wire Slack alerts in both. Run for five business days. At the end, score on five axes:
- False positives: how many alerts fired that weren't real changes?
- Time to alert: how long from change to message in Slack?
- Alert content: could you act on the alert from your phone?
- API ergonomics: how long does it take to create a monitor via REST?
- Total cost: at the frequency and feature set you actually need.
The winner will be obvious. If it isn't, neither one is right and you should evaluate a third option.
When OnChange is the answer
We build OnChange. The product is opinionated about who it's for. If your team writes code, ships changes regularly, watches both pages and APIs, and wants sub-minute checks priced into a self-serve plan, OnChange is built for you. If you also need WCAG accessibility scans (especially in an agency context) or you want every detected change to be matched against the commits that landed in the same window, OnChange is one of the few tools that ship those out of the box.
If the buyer is non-technical and the use case is "watch a few competitor landing pages and email me", a tool like Visualping will feel more native. We're honest about that on every comparison page.