7 min read
Get an email alert when a web page changes
Alexandra SwanCustomer Operations LeadThe short answer
To get an email when a web page changes, paste the page URL into a change monitoring tool, select the part of the page you care about rather than the whole page, say what should trigger the alert, and add your email address. You then get a message the moment that part changes, showing the old value and the new one side by side.
Set up an email alert in four steps
The whole setup takes about a minute and needs no code, no browser extension, and nothing left running on your machine. The checks happen on a server, so it works while your laptop is closed.
- Copy the URL of the page you want to watch. Use the specific page, not a category, search, or feed page, because those reorder themselves constantly and will fire alerts about nothing.
- Paste it in and let a snapshot load, so you can see exactly what is being watched before you commit to it.
- Say what should trigger the alert, in plain English. Something like 'alert me when the price drops' or 'tell me when the status changes'. This narrows the watch to the thing you named and ignores the rest of the page.
- Add your email address and pick how often the page should be checked. You get a message the moment the change happens, with the old value and the new one in the email itself.
That last detail is the one worth insisting on. An alert that only says the page changed sends you back to the page to work out what happened, which is most of the work you were trying to avoid.
Choosing how often the page is checked
The right interval is set by how fast the thing you care about disappears, not by how important it feels. Checking a slow page every 5 minutes does not make you better informed, and checking a fast one daily means the answer arrives after it stopped mattering.
| Check every | Right for | Why |
|---|---|---|
| 5 minutes | Restocks, ticket releases, flash sales, sanctions and status pages | Other people are racing you, or the exposure window is measured in minutes |
| Hourly | A competitor's pricing page during a launch, a job board, a tender portal | Fast enough to act the same day, quiet enough to ignore for a week |
| Daily | Terms of service, privacy policies, vendor documentation, long-running competitor watching | These pages change rarely, and the response is measured in days anyway |
Why most page change alerts become noise
The usual reason people abandon change monitoring is not that it failed to detect a change. It is that it detected all of them.
A modern page is full of things that move for reasons unrelated to why you are watching: a rotating banner, a view counter, a "3 people are looking at this" widget, a cookie notice, a recommended products carousel, a timestamp in the footer, an A/B test serving you a different variant. Watch the whole page and every one of those counts as a change.
After three or four alerts that turn out to be nothing, you stop opening them. The monitoring is still running and still reporting, and it has stopped working, because the failure is in whether you read it.
How to stop false alerts
All the fixes come down to narrowing what can trigger the alert.
- Watch one element instead of the page. Select the price, the headline, the status line, the stock label. Everything outside the selection loses the ability to fire.
- Describe the change rather than the region. Saying 'alert me when the price drops' does not fire when the price rises or when a banner rotates above it.
- Point at the specific page, not a listing. Product pages are stable; search results and category pages reorder on every load.
- Slow the interval down for pages that change slowly. A daily check on a policy page produces one true alert a quarter instead of fifty ambiguous ones.
A monitor you still trust after a month is worth more than one that catches marginally more and gets muted in week two.
The alternatives, and when they are enough
Change monitoring is not always the answer. It is worth knowing when something simpler will do.
Monitoring earns its place when the page will not tell you, the change is an edit rather than a new item, and being late has a cost.
The site's own notifications
If the page offers a back-in-stock alert, a price drop watch, or a mailing list, use it. It is free and it is authoritative. The catch is that the site chooses what counts as newsworthy, and it is rarely the thing a competitor or a regulator would rather you did not notice.
RSS
Where a feed exists, it is a clean solution. Feeds are increasingly rare outside blogs and news, and they carry new items rather than edits, so a reworded clause on an existing page never appears in one.
A script you write yourself
Fetching a page on a timer and diffing it is an afternoon's work. Keeping it alive is the part people underestimate: pages start rendering client-side, requests get blocked, the selector you keyed on gets renamed in a redesign, and your cron job reports success while watching nothing. The maintenance, not the build, is what makes this the expensive option.
Where the alert should land
Email is the right default because it is the one channel everyone already reads, and because an emailed diff is a record you can forward, file, and search months later.
For anything a team acts on rather than one person, route it to the channel where the work happens as well. A price change that reaches a shared channel gets picked up by whoever is free. The same alert in one person's inbox waits for them to come back from leave.