A false positive is an alert for an outage that never happened: your service was up, but the check said otherwise. Hyperping confirms every failure from multiple regions before it opens an outage, and this page covers the rest of what you can tune.
Most fake alerts come from one of three places:
Checks rotate through your selected regions, one region at a time. When one of them fails, the failure is not trusted on its own:
check from London
|
v
FAILURE
|
v
+-----------------------+
| instant double check |
| from your other |
| regions |
+-----------------------+
|
+-------+-------+
| |
all fail any succeeds
| |
v v
outage opens no outage
alerts sent no alert
kept in the logsBad status code, a broken assertion, an unreachable host, or a timeout. Nothing is sent to your team yet.
The double check runs at once, not on the next interval, so a confirmed outage still reaches you in seconds.
If the other regions answer normally, no outage opens and no alert goes out. The failed check stays visible in the monitor's logs.
The probes also run on a mix of hosting providers (AWS, Scaleway, DigitalOcean) across 18 regions, so a routing problem at one provider cannot fail every check at once.
| Setting | What it prevents |
|---|---|
Alert delay (alerts_wait) | Alerts on blips that resolve on their own. With a 5 minute delay, a 2 minute outage never pages anyone. |
| Expected status code | Down alerts on endpoints that legitimately answer 401, 403 or 404. |
| Follow redirects | Down alerts on a 301 or 302 that is the intended response. |
| Regions | Single-path failures. More regions mean more independent confirmations. |
| Maintenance windows | Alerts during a planned deploy or migration. |
| Grouped alerts | Ten notifications for one widespread incident. |
The alert delay lives in the monitor's Notifications tab, or in the alerts_wait field of the update monitor API, in minutes. Everything else is in the monitor settings.
Open the monitor's logs first. They show the status code, the response time and the region for every check, which usually points straight at the cause.
Your browser is not the probe. Look for a status code outside your expected range, a redirect that is not followed, or a text assertion that no longer matches the page. Logs show what Hyperping actually received.
A WAF, a bot filter or a rate limiter is blocking the probes. Datacenter IPs trigger these rules more often than residential traffic. Allow the probe regions in your firewall, or raise the rate limit for them, and lengthen the check interval if the endpoint is expensive.
Text assertions break when the page text changes. Assert on something stable, like an element that only renders on a healthy page, rather than marketing copy. See keyword monitoring.
Schedule a maintenance window for planned work, or pause the monitor for the duration of the migration. For rolling deploys that drop a few requests, an alert delay of 2 to 3 minutes is usually enough.
Browser checks fail on any broken assertion or on the 2-minute run timeout. Open the run's screenshot, video and Playwright trace to see where the script stopped. Failed runs are already retried from a different region before an outage opens. See browser checks.
That is a regional problem, not a false positive, and it is worth investigating: a CDN edge, a DNS record or a peering route can be broken for part of the world while the rest is fine. Compare response times per region in the logs.