Whole pages contain unrelated movement
Navigation experiments, recommendation modules, footers and campaign banners can change around a stable price or policy section that is the actual monitoring objective.
Targeting, normalization and notification policy
Keep the evidence. Remove the alert noise.
Control what enters the comparison, define what qualifies for attention, and preserve quiet changes in history so filtering does not erase the record you may need later.
- Target
- CSS or XPath
- Qualify
- Values + meaning
- Outcome
- Notify or retain
Sample policy evaluation
Pricing monitor · rule set 07
Source target
#pricing-table
Text threshold
2.0% minimum
Value condition
price increased
Meaning rule
customer cost changed
DELIVERY DECISION
The monitored pricing region changed above threshold and increased customer cost. Send email and webhook; retain the complete diff.
Four unrelated page updates were removed before this decision.
Alert fatigue starts before the notification channel.
A monitor becomes noisy when irrelevant content enters the comparison, volatile values survive normalization and every remaining difference is treated as equally urgent.
Dynamic values produce repeat events
Dates, counters, cache keys and generated identifiers can create a technically different response on every check while conveying the same customer-facing state.
Binary alerting discards useful nuance
If the only options are notify or ignore, teams either accept a crowded channel or lose a historical record of low-priority edits that later explains a larger change.
Filter in layers, from source to destination.
Each layer answers a different question: what part should be compared, what variance is known, what changed materially and who should receive the result.
CSS and XPath targeting
Restrict a monitor to the stable element that contains the price, clause, stock label, release note or table you actually own.
Normalization patterns
Remove known volatile strings before hashing and diffing so timestamps or generated identifiers do not control the monitor state.
Change thresholds
Require a meaningful text or visual percentage before a candidate difference becomes a recorded change worth evaluating further.
Keyword and value conditions
Qualify events around the presence, movement or tracked value that matters instead of treating every changed sentence as equivalent.
Natural-language rules
Describe a business condition in plain language and evaluate it against the bounded change record rather than an unrestricted live page.
Quiet history and routing
Retain a low-priority event in the timeline, notify a human channel or send a qualified webhook according to the monitor's policy.
Remove noise at the earliest reliable layer.
Narrowing the source is more dependable than adding complex logic downstream, while a preserved timeline keeps the final delivery decision reversible and explainable.
- 01
Select the meaningful surface
Choose the full source or a stable HTML element, visual rectangle, JSON endpoint, sitemap or robots.txt document.
- 02
Normalize known variance
Exclude only the timestamps, generated values and visual areas that are already understood and operationally irrelevant.
- 03
Evaluate the recorded change
Apply thresholds, keywords, value movement, confidence and optional natural-language or semantic conditions.
- 04
Retain or route
Keep quiet evidence in history or deliver the qualified event through email, Slack, Discord or a signed webhook workflow.
Every exclusion trades sensitivity for quiet.
Rules should be narrow, inspectable and attached to the consequence you are trying to detect—not accumulated until the dashboard happens to look calm.
- Prefer a stable selector over a long list of negative keywords. Removing irrelevant input is easier to explain and less likely to suppress a new kind of important change.
- Review normalization expressions against representative before-and-after content; an overly broad pattern can remove a value that later carries business meaning.
- Keep quiet changes visible in history when future investigation may need them. Notification suppression should not rewrite the evidence record.
- Treat natural-language and semantic rules as triage support. Material legal, security and financial changes still deserve direct review of the stored source evidence.
Continue with the related workflow.
Questions about change detection rules
Before you add the first monitor
- Should I use a selector or an alert rule?
- Use a CSS or XPath selector when only one stable page region matters; it removes unrelated content before comparison. Use an alert rule when the complete change should be retained but notification depends on a value, keyword, threshold or meaning. The most dependable setup often combines a narrow selector with a simple rule.
- What happens to a change that does not match the alert rule?
- The evidence can remain in the monitor timeline as a quiet change even when no notification is sent. Detection and delivery are separate decisions, so suppressing an alert does not require pretending that the underlying page stayed identical.
- Can OnChange ignore timestamps and other changing values?
- Yes. Normalization patterns can remove known volatile text before comparison, and visual ignore rectangles can exclude dynamic screenshot areas. Keep each exclusion as narrow as possible so an important edit cannot disappear with the noise.
- How do natural-language change rules work?
- A natural-language rule describes the condition that should qualify for delivery, such as a plan becoming unavailable or a cancellation period becoming shorter. OnChange evaluates that rule against the recorded change evidence. Pro and higher plans can also use semantic-only mode for meaning-equivalent wording changes.
Start with the smallest surface that carries the decision.
Create the monitor first, then add only the selector, normalization and delivery rules that explain a real source of noise.