SignalWatch 4 min read

How to monitor a vendor's status page or changelog

Vendors post incidents and breaking changes on pages nobody re-reads. Watch the public URL, narrow it to the incidents block, and get the diff in Slack or email.

Your payment provider, your email API, your host, your DNS: each has a status page and most have a changelog. When something breaks or is about to change, that is where it is written first. Nobody on your team reads those pages on a schedule. Put the URL on a monitor and let the diff come to you.

Why the email subscription is not enough

Many status pages offer an email or RSS subscription. Use it if it exists. It is still worth monitoring the page itself:

  • Subscriptions cover incidents the vendor chose to declare. A quiet edit to a "degraded performance" note, or a line added to a maintenance window, is often not a notification.
  • Changelogs are rarely subscribable at the detail you need. A deprecation line added halfway down an existing release is an edit, not a new post.
  • Email goes to whoever signed up, who may have left. A monitor sends to a channel.

The habit is the same one in how to get alerted when a web page changes: a scheduled fetch of the public URL, a comparison of visible text, and an alert with a diff.

Set up the monitor

SignalWatch fetches a public HTTP(S) URL on a schedule and compares the visible text. When it changes, you get a unified diff by email, Slack, Discord, or an HMAC-signed JSON webhook. Free: 3 monitors, a check every 15 minutes, 45 days of history, no card. You can check a URL before you create an account.

  1. Pick the page a human would read, not the API endpoint. For a status page that is usually the root. For a changelog it is the releases or changelog page.
  2. Open it in a private window. The text you care about must be in the page for a logged-out visitor. A dashboard behind a login is out of scope.
  3. Create the monitor and send the first alert to email. Move it to Slack or Discord once you trust it.
  4. Wait for the first diff. Status pages are noisy by design. The first alert tells you what to ignore.

Cut the noise

Status pages contain things that change on every fetch: a "last updated" clock, a 90-day uptime bar, a count of days since the last incident, a rotating footer. Left alone, those will train you to mute the channel.

  • CSS selector. Limit the comparison to the incidents region or the current-status block. On most status pages that is one container near the top. On a changelog, it is the list of releases.
  • Ignore regex. Drop timestamps and relative times. A pattern for an "Updated 5 minutes ago" line:
Updated\s+\d+\s+(?:seconds?|minutes?|hours?)\s+ago
  • Minimum change. Set a floor so a one-character tweak in a widget does not count. Keep it small. A real incident is usually a new paragraph, not a swapped digit.

The same controls, with a worked example for a pricing page, are in how to monitor a competitor's pricing page.

Where the alert should land

  • Slack or Discord when the team already has an ops or alerts channel. The diff is in the message. Someone reads it in context.
  • Email when it is one person's job to know.
  • Webhook when another system should hold the event. The webhook is HMAC-signed JSON on the same account as the dashboard, and there is a REST API with OpenAPI docs for creating monitors from code. Read the docs for the payload before you build a consumer.

Two things the same monitor tells you

SignalWatch does not only compare text. The same monitor alerts when the URL goes down and when it recovers, and when its TLS certificate is inside 14 days of expiry, then again at 3 days.

For a vendor status page, downtime of the status page itself is worth knowing. A status page that is unreachable during an incident is a common failure. For your own pages, the certificate check is the one that saves a weekend. See how to monitor TLS certificate expiry.

How many monitors

Three on the free plan. Spend them on the vendors whose outage would stop your product: payments, auth, the host. Pro ($12/month or $79/year) raises the cap to 50 monitors at 5-minute checks. Business ($29/month or $199/year) is 500 monitors at 2 minutes. For a status page, 15 minutes is usually fine. The shorter intervals matter when you also want tighter downtime checks on your own URLs.

Checklist

  • The URL is the public, human-readable status or changelog page.
  • Selector set to the incidents or releases block after the first noisy diff.
  • Ignore rule for clocks and relative times.
  • Alert channel is one that the team already watches.
  • Three free monitors spent on the vendors that would take you down.