SignalWatch 3 min read

Page change monitoring vs uptime monitoring

Uptime tools tell you a URL is down. Change monitors tell you the words moved while the status code stayed 200. Most teams that care need both jobs named.

Use uptime monitoring when the question is "is this URL answering?" Use page change monitoring when the question is "did the visible text on this URL change?" A page can return 200 all afternoon and still rewrite its pricing table. An uptime ping will stay green. A change monitor will send a diff.

Uptime monitoring

You pick a URL (or a host). Something requests it on a schedule and alerts when it fails, times out, or leaves an expected status range.

That is the right tool for "the site is down" and "it recovered." Products in this category (UptimeRobot and many others) are built around availability, regions, and status pages. They are not built to tell you that a sentence on /pricing was edited.

Page change monitoring

You pick a public URL. Something fetches the page, compares visible text with last time, and alerts when it moved — ideally with a unified diff so you see what changed.

SignalWatch does that job. The same monitor also alerts on downtime and recovery, and when the TLS certificate is inside 14 days (again at 3 days). So one SignalWatch monitor covers change + uptime-of-that-URL + certificate date. Free: 3 monitors every 15 minutes, no card. Pro is $12/month or $79/year.

It does not replace a multi-region uptime mesh for a large production estate. It does replace "I only have UptimeRobot, why didn't I see the price drop?"

Side by side

  • Question. Uptime: is it up? Change: did the content move?
  • Typical alert. Uptime: down / up. Change: diff of text (and optionally down / cert).
  • False quiet. Uptime stays quiet when HTML changes and HTTP stays 200. Change stays quiet when the host dies only if you are not also watching downtime — SignalWatch watches both on the same monitor.
  • Target. Both: a URL you can reach. Change tools that compare text need the content in the response; login walls need a different product.

When uptime alone is enough

  • You only care that the homepage responds.
  • Content edits are someone else's problem (or they ship through a process you already trust).
  • You already run a dedicated uptime stack and separately watch content another way.

When change monitoring is the missing piece

  • Competitor or vendor pages whose wording you act on.
  • Your own pricing, docs, or status page, watched from the outside.
  • Compliance or policy pages where a silent edit matters more than a blip of downtime.

Setup notes: how to get alerted when a web page changes. Cost-first path: cheapest way to monitor a web page for changes.

When to run both

Many operators keep a general uptime tool for the whole property and SignalWatch on the few URLs whose words matter. They are different questions. SignalWatch's downtime alert on those URLs is a convenience, not a reason to delete a fleet-wide uptime check.

Broken links are a third question — see website change monitoring vs broken-link monitoring.