Uptime monitoring vs change monitoring: who sets the threshold

Your status page is green. Every check passed. Response times are boring.

Meanwhile a vendor added a subprocessor in Singapore, a competitor cut their free trial from 14 days to 7, and the API you build on quietly moved an endpoint into a "legacy" section of the docs. Nothing went down. That was never going to page you.

Uptime monitoring and website change monitoring get filed next to each other because they both watch URLs on a schedule and both send you a message. They answer different questions, and the gap between them isn't technical. It's about who gets to set the threshold.

"Is it up?" is a question a machine can answer alone

An uptime check has a definition of failure that doesn't need you in the room. Request the URL, look at the status code, look at the clock. HTTP 200 in under some number of seconds from three regions: pass. Connection refused, 503, timeout: fail, page someone.

That threshold is objective and portable. It means the same thing for your marketing site and your payments API. Which is why uptime monitoring commoditized fast and why the tools are cheap.

The tools are also honest about the limits. UptimeRobot's own docs make the point that a 200 tells you the server answered, not that it answered correctly. You can serve a perfect 200 with an empty <div> where the checkout used to be.

The usual patch is keyword monitoring: check that the word "Sign in" still appears in the response, alert if it doesn't. That's useful. It's also a boolean on a string you had to choose in advance, which means it can only catch the failure you already imagined.

And on a lot of modern pages, the string isn't in the response at all.

Source: HTTP Archive Web Almanac, SEO chapter, 2020 edition.

Roughly a fifth of the visible words on a median desktop home page only exist after JavaScript runs. A raw fetch sees the shell. That's fine for "did the server answer." It's not fine for "what does the page say."

"What did they change?" is a question only you can answer

There is no universal definition of a meaningful change. A seat price moving from $12 to $15 is a fire drill for your pricing team and irrelevant to everyone else on the internet looking at the same page. A rotating "trusted by" logo strip is noise to you and the entire point of the page to the person who built it.

So the threshold has to come from you. In modsignal that's the prompt: one plain sentence describing the change you care about, which the semantic tier evaluates against the fresh page and the last snapshot. Not "did this page change" but "did the thing I described happen."

Same page, different prompts, different answers. Point one prompt at a pricing page asking about plan tiers and limits, another asking whether the free trial length changed, and they'll fire on different days. That's the design, not a quirk. If you're writing your first one, the difference between "the page changed" and "the thing I care about changed" is where most of the craft lives.

Uptime monitoring ships with its threshold. Change monitoring ships with a blank.

The real split is ownership, not correctness

PageCrawl frames this as "is my site reachable" versus "is my site correct," which is a good line and true as far as it goes. It also concedes the bigger half of the category without meaning to.

Most change monitoring is not about your site.

You can instrument what you own. Health endpoints, synthetic transactions, log drains, a status page, an on-call rotation. None of that exists for your competitor's pricing page, your vendor's DPA, the tender portal your bid team lives on, or the changelog where an API you depend on announces its deprecations. There's no webhook to subscribe to. There's no support ticket to file. The page is the API.

That's the actual dividing line:

• Pages you own → you control the instrumentation, so uptime and correctness are both solvable from the inside.
• Pages you don't own → the rendered page is the only signal, and nobody on the other side has any obligation to tell you it moved.

The second category is where the money is. Deprecation windows start when the notice is published, not when you notice it, which is why monitoring the changelogs your product depends on is a real engineering practice. GDPR Article 28 objection windows work the same way. The clock is already running.

There's a third case neither category handles well. In June 2026, Polymarket users were reportedly served malicious code through a compromised third-party script. No server was breached. Nothing went down. Every uptime check in the world would have stayed green through it, because from an HTTP perspective the site was working perfectly. What changed was what the page said and did.

Two alerts, two half-lives

This is the difference nobody compares, and it's the one that should decide your tooling.

An uptime alert is disposable. It exists to get a human to look at a dashboard in the next four minutes. Then it resolves itself, and the resolution email joins the other resolution emails. Nobody forwards "the site is back up" to legal.

A change alert has a second life. It gets pasted into a Jira ticket. It goes to the security team as evidence a vendor added a subprocessor. It gets quoted in a competitive briefing three weeks later, by someone who wasn't in the original Slack thread and has no intention of reopening the page to check.

That asymmetry is the whole argument for putting the evidence inside the alert instead of a link to go look. An uptime alert can get away with being a pointer. A change alert can't, because by the time the second reader gets to it, the page has probably changed again.

So a modsignal alert carries the finding, not the address of the finding: one sentence saying what changed, the before and after excerpts, a confidence score from the model, a full-page screenshot on the browser agent tier, and a link to the monitor timeline for anyone who wants the full history. The bar we hold ourselves to is that you should be able to forward it or paste it into a ticket without anyone reopening the page.

The timeline is the source of truth. Slack, email, webhooks and the RSS feed are copies of it.

Noise costs differently in each

Uptime monitoring has a number to justify its aggression. ITIC's enterprise surveys have put an hour of downtime above $300,000 for most mid-sized and large organizations. That's self-reported, so treat it as an order of magnitude rather than an invoice. When the downside is that big, a few false pages a month is a rational trade.

The industry pays for it. PagerDuty has reported responders seeing something like 50 alerts a week, with only a small single-digit percentage actually actionable. That ratio is survivable when the misses are catastrophic.

Change monitoring has no such excuse. Nothing is on fire. If a monitor tells you a competitor changed their pricing and they didn't, you spent four minutes and a small piece of your willingness to open the next one. There's no upside to balance against it. Which is why the goal for a change monitor is silence, and why a monitor that cries wolf is worse than no monitor at all. The no-monitor version at least doesn't train you to ignore things.

Different failure economics, different alert design. An uptime tool that's slightly trigger-happy is doing its job. A change tool that's slightly trigger-happy is being uninstalled.

Can you use one for the other?

Both directions get tried. One of them sort of works.

Uptime tool as a change monitor. Keyword monitoring does real work on a narrow class of question: does this exact string still appear on this page. Watching for "Out of stock" to disappear is a reasonable use of it. What it can't do is answer "did the price go up," "did the notice period shrink," or "did they add a subprocessor," because all three require reading text that didn't exist when you wrote the check. And on a client-side rendered page you may be checking an HTML shell that never contained the string in the first place.

Change monitor as an uptime tool. Don't. We'll say it plainly about our own product: modsignal is not uptime monitoring and doesn't pretend to be. Our fastest check interval is every 2 minutes, on the Business plan. There's no escalation policy, no on-call schedule, no phone call at 3am, no multi-region consensus before declaring an incident, no incident timeline, no SLA reporting. If your site goes down at 03:14 you want a tool built for exactly that, and we are not it.

What to actually run

• You own the thing and need to know it's unreachable → an uptime tool. UptimeRobot, Better Stack, Pingdom all do this well and all have entry tiers cheap enough that this isn't a budget conversation. We're not quoting their prices, because they move; check their pricing pages.
• You own the thing and need to know someone shipped a wrong price, a broken legal page, or a stale docs link → a change monitor on your own page, exact diff tier.
• You don't own the thing → a change monitor, and there isn't really an alternative. There's no health endpoint on someone else's DPA.
• You need to know at 3am → uptime tooling, every time. Change monitoring is a business-hours discipline.

Most teams that take either seriously end up running both, and they don't compete for the same budget line. One is infrastructure spend. The other is competitive, legal or procurement spend, and it usually gets bought by a different person entirely.

Uptime monitoring asks a question with one right answer, and any competent tool can find it. Change monitoring asks a question whose answer depends on what your team is trying to decide this quarter. The interesting part isn't the checking. It's the threshold, and the threshold is yours.

modsignal's free plan is 3 monitors on daily checks, no card, if you want to point one at a page you don't own and see what a quiet month looks like.