How to get alerted when a web page changes

To hear about a change on a public page, put that URL on a schedule and compare the visible text from one check to the next. An alert with a diff is the useful outcome. A tab you meant to revisit is not a monitor.

Checking by hand

Opening the page every morning works until the day you do not. Pricing, a status page, a changelog, a policy, a docs page: the edit is often a sentence, and nothing announces it.

Hand-checking also has no diff. You are relying on memory of what the page said last Tuesday.

Browser extensions

An extension can highlight a page you have open. It runs when the browser runs, on that machine, for pages you remember to visit. It is a reading aid. It is not a check that still happens when the laptop is shut.

RSS, when it exists

RSS is the right tool when the site publishes a feed and you want new items: posts, releases, tagged versions. It is the wrong tool when the thing that matters is an edit to a page that is already published.

A pricing page rarely has a feed entry called "we changed the Pro plan". The HTML changes. The feed, if there is one, stays quiet.

Monitor the URL

SignalWatch (opens in a new tab) fetches a public HTTP(S) URL on a schedule and compares visible text. When the text changes, the page goes down, or the TLS certificate is inside 14 days, it can email you, post to Slack or Discord, or send an HMAC-signed JSON webhook. The change alert includes a unified diff.

Free plan: 3 monitors, a check every 15 minutes, 45 days of history, no card. You can check a URL before you sign up. Pro is $12/month or $79/year (50 monitors, every 5 minutes). Business is $29/month or $199/year (500 monitors, every 2 minutes).

The same monitor covers three events:

Visible text changed.
The page went down, and when it recovered.
The certificate on that URL is inside 14 days, with another alert at 3 days. Details are in how to monitor TLS certificate expiry.

Narrow the comparison

Whole-page diffs lie. A page can "change" because a footer year rolled, a review rotated, or an ad loaded different copy.

Use the controls the product actually has:

CSS selector. Limit the comparison to one region, such as main or the node that holds the article.
Ignore regex. Skip a pattern you know is unstable. A time of day is a common one:

\b\d{1,2}:\d{2}\s?(?:am|pm|AM|PM)?\b

Minimum change. Ignore a tiny edit so a single swapped character in a widget does not page you.

Start broad. If the first alert is noise, add a selector before you add a second URL. A worked example for pricing pages is how to monitor a competitor's pricing page.

Where the alert should go

Email is the right default. You already have a place it can land, and the diff is in the message.

Slack or Discord is better when a channel already exists for that site. A webhook is better when another system should store the event. The webhook is HMAC-signed JSON, on the same account as the dashboard. There is also a REST API and OpenAPI docs if you want to create monitors from code. This guide does not invent a payload. Read the docs on the product site before you bind a consumer to fields.

A page worth monitoring

Good targets are stable URLs with text a person would act on:

Your own pricing, docs, or status page, so you notice an edit you did not ship.
A vendor status page or changelog.
A policy or terms page you depend on.
A competitor's pricing or feature page.

Poor targets are pages that are mostly a clock, a stock ticker, or a feed of new rows. You will train yourself to ignore the alerts.

Checklist

The URL is public. A logged-out window shows the text you care about.
One monitor per URL, not one monitor for a whole site. A site full of links is Mortise's job (opens in a new tab).
Selector and ignore rules added after you have seen one noisy diff, not before.
Alert channel chosen.
Free plan used first: 3 URLs is a real limit, so pick pages you would be annoyed to miss.