Last week we launched OR:ON. Today we want to talk about the thing that pushed us to build it: Hexowatch’s false positives.
If you used Hexowatch, you know the routine. An email says the page changed. You open two screenshots side by side. You squint. Nothing you care about is different. You close it. After the tenth one, you stop opening them.
It was one of the most common complaints we got for five years.
What actually set off the alerts
We wrote about this so often that “Why am I getting false positives?” had its own section in our FAQ. Here’s the honest list of what triggered most of them:
Timestamps. “Updated 4 minutes ago” or a date in the footer. Different on every check, so every check was a “change.”
Rotating banners and ads. A new ad loads, the hero slider moves to slide three. The visual monitor sees new pixels and fires.
Session elements. A cart counter, a “Welcome back” message, a random A/B test variant. Each visit looked a little different from the last.
Tiny CSS shifts. A font loads a fraction of a second late and pushes the layout down two pixels. To a screenshot diff, that’s a change across the whole page.
Half-loaded pages. The check took its snapshot before the page finished loading. Half the content was missing, so we reported a change. Next check it loaded fully, and we reported a change again.
Block pages. A site served a Cloudflare challenge instead of the real page. Hexowatch compared the challenge to yesterday’s page and called it a change.
Our browser saw a different page than you did. Old sites, and sites that don’t handle different screen sizes, often rendered one way for us and another way for you.
Then there was the opposite problem. HTML element monitors were precise, so we recommended them for prices. But they were tied to a spot in the page code. When a site rebuilt its markup, the price could stay exactly the same and the monitor would still break or fire. Our own FAQ said it plainly: that’s not a bug, that’s how the web works.
We were right about the web. We were wrong to stop there.
What we told you to do about it
Our advice was always some version of “set it up better”:
Combine Visual and HTML monitors so design changes don’t trigger alerts.
Pick stable elements. Exclude the dynamic parts of the page.
Check less often. Five pages every 15 minutes is 480 visits a day, enough to get blocked on a small site.
Book a Concierge session and we’ll tune it until false positives are close to zero.
All of that worked, sometimes, but it meant every useful monitor needed someone who understood selectors, delays, and regions to build it, then fix it when the site changed. Most people don’t have that person. So they did the reasonable thing and muted the alerts.
In January we finished months of backend work: smarter page loading, better diff detection, more retries. Success rates went up and false positives dropped. They didn’t go away, because the core problem was still there.
The core problem
Hexowatch compared two versions of a page, as code or as pixels, and reported the difference. It had no idea what the difference meant. To Hexowatch, a new timestamp and a new price were the same thing: some characters changed somewhere on the page.
Every fix we shipped was a rule. Ignore this area. Track that element. Wait three seconds longer. Rules work until the site changes, and sites change all the time.
There’s a name for what this does to people. In hospitals it’s called alarm fatigue. Reviews of hospital alarm studies found that 72% to 99% of clinical alarms are false. Johns Hopkins counted about 350 alarms per patient per day. Nurses react the way you’d expect: they turn the volume down, widen the limits, or tune them out, and the real alarm gets ignored with the rest. A monitoring tool with a bad alert ratio does the same thing to you, with lower stakes.
How OR:ON handles each one
OR:ON starts from what you said matters, then looks at the page. That changes how each of those causes plays out:
Timestamps, banners, ads, session elements. You asked about the price or the job list. A new ad or a new date is neither, so you don’t hear about it.
Markup redesigns. OR:ON looks for the price, not a path in the code. If the site rebuilds its layout and the price stays the same, there’s nothing to report.
Cookie notices. It can close them before taking the snapshot, so a consent popup never ends up in the comparison.
Block pages and failed loads. A page Watch can retry through a residential proxy instead of reporting a broken page as a change. For stubborn sites, use the proxy on every check.
Changes you only care about in one direction. Limit a Watch to something new or something removed, and the other direction stays quiet.
When an alert does come, it says what changed in plain words. You don’t open two screenshots to find out it was a banner.
What it still won’t fix
It’s not perfect, and we’d rather say so now.
If you describe what matters vaguely, the alerts will be vague too: “tell me about changes” gets you far more email than “tell me if the Pro plan price changes.” And sites keep finding new ways to block automated visitors. We’ll keep catching up.
Bring back one monitor you muted
You probably have a Hexowatch monitor you stopped reading because it cried wolf. Start there.
Do it yourself: open orion.hexowatch.com, paste the same URL, and write one sentence about what you actually wanted to know (sign in with your Hexact account).
