A false positive is an alert that fires when your service is actually healthy — a check failed briefly but the service recovered on its own. False positives erode trust in your monitoring because teams start ignoring alerts.
This article explains what causes false positives and what you can do to reduce them.
The internet has brief, random failures. A single packet loss, a DNS hiccup, or a momentary routing problem can cause one check to fail even when your service is perfectly healthy. These failures typically last one check cycle and then disappear.
Application servers sometimes take slightly longer to respond during garbage collection, connection pool saturation, or brief CPU spikes. A single check during that window may time out even though the service recovers immediately.
If you recently updated DNS records, different resolvers may return different results temporarily. Checks from PulseAPI's infrastructure may hit a resolver that hasn't propagated the new record yet.
During a rolling deploy or server restart, there's a brief window where some checks may fail as processes come up and down.
If you're alerting on response time thresholds, consider whether the alert is necessary at the configured threshold. A single spike to 2.5s doesn't necessarily mean your service is down. Consider raising the threshold or switching to a status code rule (which only fires on actual HTTP failures, not latency spikes).
If a false positive fires and then immediately recovers, the cooldown period on your alert rule determines how quickly a notification is sent. A short cooldown (e.g., 1 minute) will always notify on the first failure. Consider whether the trade-off is acceptable for your team.
Instead of alerting on every failed check, create a rule that fires when uptime drops below a percentage over a time window (e.g., uptime < 99% over the last 24 hours). This smooths out transient blips — you only get alerted if there's a sustained degradation, not a one-off hiccup.
To create this type of rule, see Alert Rule Conditions: Uptime Percentage.
On Professional and Team plans, the Alert Accuracy Dashboard tracks your false positive rate over time and can suggest threshold adjustments. You can also use the Auto-Tune feature to let PulseAPI automatically adjust thresholds based on your historical data.
See Alert Accuracy Dashboard and Auto-Tuning Alert Thresholds.
For mission-critical services, it's often better to accept a low false positive rate than to miss a real failure. Tune aggressively if you need to, but don't tune so aggressively that real incidents go undetected.
The right balance depends on your tolerance for alert noise vs. your tolerance for missing real failures. High-severity rules (Critical, High) should have tighter thresholds and accept some false positives. Lower-severity rules can be tuned more conservatively.
Still have questions? Contact support.