Why website monitors miss changes — and how to tell

A page changed and you never got an alert. That's a frustrating, generic symptom — but it almost never has a generic cause. In practice it's one of six specific things, each with a different fix, and telling them apart is the actual troubleshooting step most people skip.

1. Polling gaps — the change happened and reverted between checks

Any interval-based monitor (which is most of them, ours included on standard web/price trackers) only knows what the page looks like at each check. If a page changes and then changes back before the next check runs, the monitor never saw the intermediate state — it compared "before" to "after" and they matched. This is most common on pages that flicker: a price that briefly drops during a flash sale and resets, a "sold out" banner that toggles on and off as stock trickles in and out. A faster check interval narrows this gap but never fully closes it — there's always some interval, even if it's a couple of seconds. See what "real-time" monitoring actually means for how check frequency, detection, and delivery are three separate numbers.

2. JavaScript-rendered content that isn't in the raw HTML

Some sites build their visible content client-side — the HTML a server returns is a near-empty shell, and the actual text, price, or status is injected by JavaScript after the page loads in a browser. A monitor that fetches raw HTML (cheap, fast, and fine for most sites) will diff the shell, not the rendered content, and can miss changes entirely or flag changes that aren't real. Monitors that need to catch this kind of page have to run an actual headless browser to render JavaScript before comparing — meaningfully more expensive per check, which is part of why not every tool does it for every page by default. If a monitor never seems to catch changes on a specific site, this is one of the first things worth checking: view the page's raw source (not the rendered DOM) and see if the content you care about is actually there.

3. Content behind a login or paywall

Some monitoring tools will attempt to log into a site on your behalf to watch gated content — this deliberately isn't something TrackerHub does. It only watches publicly accessible content: no stored logins, no paywall bypass, no CAPTCHA defeat. If the thing you want watched sits behind an account, that's a real limitation, not a bug, and it applies to every tool that takes the same stance. Worth checking directly whether the page you're pointing a tracker at is actually reachable logged out, in a private/incognito window, before assuming a miss was the monitor's fault.

4. Rate limiting and blocking

Sites — especially ones that get scraped a lot, like ticketing, sneaker, and social platforms — actively push back against automated traffic: CAPTCHAs, IP blocks, or pages that quietly serve a different (often stale or empty) response to detected bots. A monitor hitting a rate limit doesn't usually announce it loudly; it might just keep getting a cached or degraded page and see "no change" because that's genuinely what it received. This is a real, ongoing arms race on high-value targets, and it's a large part of why watching X/Twitter by scraping a profile page is fragile — the official Filtered Stream API path (covered in getting X post alerts on your phone) exists specifically to sidestep this failure mode for that one platform.

5. Pages that change constantly — the noise problem

The opposite failure: a page that legitimately changes on every single check — a rotating timestamp, an ad slot, a "you might also like" carousel, an A/B test cookie — so a naive whole-page hash fires "changed!" constantly. Two bad outcomes follow from this, and both look like "the monitor missed something": either you get so much noise you stop trusting the tool and mute it (missing the real change buried in the spam), or the tool's own noise-suppression logic is tuned aggressively enough that it also suppresses a genuine change that happens to sit near the noisy elements. Monitors that extract meaningful content before comparing (rather than hashing the whole page) handle this better, but it's worth being specific with any monitor about which part of a page actually matters, when that's possible, rather than trusting default whole-page diffing on a busy page.

6. Delivery failure — detected, but the alert never arrived

This is the one that's easiest to blame on "the monitor missed it" when the monitor actually didn't. The change can be detected correctly and the alert can still never reach you, because delivery is a separate system with its own failure modes: an email provider's daily sending cap gets hit and later sends from that provider start bouncing or queuing; a webhook target is briefly down and the POST fails; a push notification gets deferred by the OS. This is not a hypothetical for us — TrackerHub has had a real incident where an email provider's cap caused a multi-day gap in delivered alerts before it was caught, which is exactly why a fallback chain of independent email providers exists now: when the primary rejects a send, the system automatically tries the next provider in the chain rather than letting the alert quietly die. That reduces this failure mode significantly. It doesn't eliminate it — TrackerHub is in beta with no uptime or delivery guarantee, and any external delivery channel (email, webhook, chat platform) can have an outage on its own end that's outside any monitoring tool's control.

A note on false negatives vs. false positives

It's worth separating two problems that get lumped together as "monitoring doesn't work": a false negative is a real change that produces no alert (the six causes above), and a false positive is an alert with no meaningful change behind it (mostly cause #5, noisy pages). They feel like opposite complaints but usually trace back to the same root — how aggressively a tool filters what counts as "changed." A tool tuned to avoid false positives (ignore small diffs, extract only meaningful content) is, almost by construction, more likely to occasionally swallow a real but subtle change. A tool tuned to never miss anything (hash the whole page, alert on any byte difference) will spam you with noise until you mute it, which produces a false negative anyway — just a self-inflicted one. There's no setting that eliminates both failure modes at once; the honest goal is getting the tradeoff close enough that you trust the tool enough to keep it on.

What to do before assuming the monitor is broken

A short checklist, roughly in order of how often each cause actually turns out to be the answer:

• Check the tracker's own check-history log first — it usually rules out or confirms a polling gap in under a minute.
• Load the page in a private/incognito window and view its raw source (not the rendered page) — this catches both JS-rendering issues and login/paywall gating at once.
• Check the notification log for a failed delivery attempt before assuming detection failed — a "changed: true" entry with no successful send is a delivery failure, not a detection one, and the fix is entirely different (check the channel, not the tracker).
• If a specific site has gone quiet after working fine for weeks, suspect rate limiting or a page structure change before suspecting the monitor generally — this is usually site-specific, not tool-wide.

How to tell which one happened