Glossary
False positive
A false positive is an alert for a problem that was not there, such as an uptime monitor reporting a site down while it is up.
Also called False alarm, False alert.
A false positive is an alert about a failure that was not happening. In uptime monitoring the usual cause is not a bug but ambiguity. The probe really could not reach the service, but the reason lay somewhere on the path rather than at the destination. A dropped packet, a saturated link, a DNS answer that was briefly wrong, or a rate limit applied to the monitor itself can each produce a failed check against a service every customer was using without trouble.
When a monitor says your site is down but it loads fine for you, check four things. First, that the monitor is checking the same address you are, including the scheme and any www. Second, whether the failure was a timeout on a slow page rather than an error. Third, whether a firewall, bot filter or rate limit is answering the monitor with a 403 or 429 while serving real visitors. Fourth, whether the failure cleared by the next check, which points at the network rather than the site.
False positive alerts matter more than their frequency suggests, because the damage compounds. The first false page is an annoyance. By the tenth, the response to an alert has changed from investigating to assuming, and the cost is paid on the day the alert is real and gets the same shrug. A monitoring system's credibility is spent, not renewed, and once it is gone it takes a long run of clean signal to earn it back.
The remedies all trade detection speed for confidence, and the right amount depends on what the alert costs. Requiring several failed checks in a row, re-checking before declaring, requiring agreement between locations, and having the prober test its own connection all reduce false positives, and all of them delay a genuine alert by some amount. The one approach that does not work is raising thresholds until the noise stops, because that looks exactly like switching the monitor off.
| Cause | What the monitor sees | What reduces it |
|---|---|---|
| A network blip | One failed check, often a timeout or a refused connection, that clears on the next check | Re-checking before it counts, and waiting for several failed checks in a row |
| A timeout set too tight | Timeouts on a page that is slow but working, often at busy times | A timeout above the page's normal worst response time |
| A firewall or rate limit | A 403 or 429 for the monitor while real visitors get the page | Letting the monitor through, or checking an endpoint the filter does not cover |
| The wrong address | A 404 or a certificate error on an address customers do not use | Checking the exact URL customers use, with the right scheme and host |
| The monitor's own network | Failures on many unrelated monitors at the same moment | A prober that tests its own connection, or checks from more than one network |
Questions
Why does my uptime monitor say down when the site is up?
Usually because the monitor is not seeing what you see. It may be checking a different address, timing out on a slow page, being blocked by a firewall or rate limit, or losing a packet on the way. Check the error it recorded: a status code and a timeout point at different causes.
What is a false positive alert?
It is an alert for a problem that was not real, such as a site reported down while customers were using it. Its opposite is a false negative, which is a real problem the monitor missed.
How do you reduce false positive alerts?
Re-check a failure before it counts, wait for several failed checks in a row before paging, set timeouts above the service's normal response time, and make sure nothing is blocking the monitor. Each of these delays a real alert a little, so tune them to what an alert costs.
Are false positives worse than missed alerts?
One missed outage costs more than one false page. But false pages add up. A team that gets many of them stops trusting its alerts, and then it responds slowly to the real ones too. That is why a steady trickle of false positives is dangerous.
What is a false negative in monitoring?
It is a real problem the monitor did not catch. A common example is a page that returns 200 OK while showing an error message, which a check on the status code alone will pass. Checking the response body for text you expect catches it.
In Uptimely
Uptimely's alerting defaults are shaped around this. A result that would make a monitor's status worse is checked a second time before it counts. An incident is declared only after 2 failed checks in a row by default, which you can set from 1 to 10 per monitor. Website and API monitors wait 30 seconds for an answer by default, adjustable from 1 to 60. The Ping monitor opens a TCP connection to port 80 rather than sending ICMP, so a firewall that drops ICMP does not make it fail. And a failure the prober's own network could have caused is discarded and left as a gap, not reported as downtime.
Uptimely re-checks a failing result once before it counts and waits for 2 failed checks in a row before it declares an incident.
Start monitoring free →Part of the Uptimely monitoring glossary — plain definitions of the vocabulary uptime monitoring, incident response and status pages are discussed in. Something here read wrong to you? Email support@getuptimely.com.