Quick Answer: False uptime alerts happen when your monitor mistakes a transient network problem for a real outage. The fix is to require stronger evidence before paging anyone: set consecutive-failure thresholds (2-3 failed checks), tune timeouts above your normal response times, monitor endpoints that reflect real user impact, and test your alert channels before you need them at 3am.
Why does my uptime monitor alert when my site is actually up?
If you have ever been woken up by a downtime alert only to find your site loading fine in your browser, you are not alone. False positives are the number one reason teams disable monitoring entirely, which is worse than noisy alerts.
The root cause is almost always the same: your monitor sees the world through a single network path. A monitoring probe in Virginia sends an HTTP request to your server in Oregon. That request crosses a dozen networks. If any hop along the way has a two-second routing blip, the check fails. From that one probe's perspective, your site is down. From every other vantage point on the internet, it never went offline.
This is not a bug in your monitoring tool. It is a limitation of checking from one location without confirmation. The internet is a statistical medium. Packet loss, brief latency spikes, and DNS resolver hiccups are normal conditions, not outages.
Single-location monitoring is responsible for the majority of false alerts. Other common causes include aggressive timeout settings (alerting when response time exceeds 500ms on a site that normally responds in 800ms), monitoring tools getting rate-limited or blocked by your firewall, and DNS propagation delays after a recent change.
How do I tune my monitor settings to reduce false alerts?
The goal is not to ignore failures. It is to require stronger evidence before you wake someone up.
Require consecutive failures before alerting. If your monitor marks a service as down after a single failed request, it is too aggressive. Set a threshold of 2-3 consecutive failures. At a 60-second check interval, that still alerts you within 3 minutes of a real outage while filtering out momentary network hiccups that resolve on their own.
Tune your timeout settings. Measure your normal response times under load first. Check your server logs or APM tool for the 95th percentile response time. Set your monitor timeout slightly above that number. If your API normally responds in 300-600ms but occasionally spikes to 1.5 seconds during deploys or traffic bursts, a 2-second timeout is appropriate. A 500ms timeout will page you every time your site gets moderately busy.
Monitor the right endpoints. A homepage returning 200 does not mean your application is healthy. Your payment API, login endpoint, and database-backed routes can fail independently. Set up separate monitors for each critical path with timeouts tuned to that endpoint's behavior. An API that normally responds in 50ms should have a tighter timeout than a report-generation endpoint that takes 5 seconds.
Overwatch lets you configure per-monitor timeouts, check intervals, and alert bindings so each endpoint gets settings that match its normal behavior instead of one-size-fits-all defaults.
What causes alert flapping and how do I stop it?
Flapping is when your monitor rapidly bounces between up and down, sending a dozen notifications for what is effectively one incident. It is exhausting and trains your team to ignore alerts.
Flapping usually means your site is hovering right at the edge of a threshold. Response time sits at 1.9 seconds with a 2-second timeout. CPU load scratches the alarm line. A single server in your load balancer pool drops out of rotation briefly. The natural variance in these metrics is enough to flip the monitor back and forth.
Fix flapping with three changes:
- Widen your timeout margin. If flapping starts after you tightened timeouts, loosen them. Add 30-50% buffer above your 95th percentile response time.
- Require consecutive failures. A single blip should never page anyone. Three consecutive failures collapse transient noise into one meaningful alert.
- Check less frequently during tuning. If you are still dialing in settings, use 60-second intervals instead of 30 seconds. You can tighten intervals once false positives are under control.
If flapping persists after tuning timeouts and failure thresholds, the problem may be infrastructure-level: an overloaded server, intermittent database connection pool exhaustion, or a load balancer health check that is too aggressive. Fix the underlying instability rather than masking it with looser monitor settings.
How should I set up alerts so false positives do not burn out my team?
Monitor settings are half the equation. Alert routing is the other half.
Route alerts to the right channels. Critical production outages should go to Slack with @channel or PagerDuty. Non-critical warnings (slow response, certificate expiring in 30 days) should go to a lower-priority channel. If every alert pages the on-call engineer, alert fatigue is guaranteed.
Test your alert channels monthly. Run overwatch alert test or your tool's equivalent against every configured channel. An alert routed to a Slack channel nobody monitors is the same as no alert at all.
Document what "down" means for each monitor. Is a 503 on your API a page-worthy incident or an expected maintenance response? Write it down in your runbook. When the alert fires at 2am, the on-call engineer should know immediately whether to roll back a deploy or wait 60 seconds for a transient blip to clear.
Track your false positive rate. After each alert, note whether it was a real incident or a false positive. If more than 20% of your alerts are false positives, your monitor settings need tuning. Teams that track this metric typically cut false alerts by 70-80% within the first month of deliberate tuning.
Frequently Asked Questions
Why does my uptime monitor alert when my site is up?
The most common reason is single-location monitoring. Your monitor checks from one network path, and a routing blip or packet loss on that path looks identical to a real outage. Your site may be reachable for everyone else while one probe reports failure. Requiring consecutive failures or checking from multiple locations fixes most of these false positives.
How many consecutive failures should I require before alerting?
Two to three consecutive failures is the sweet spot for most sites. One failure is too sensitive and catches every network hiccup. More than three adds unnecessary delay on real outages. At a 60-second check interval, three failures means you still alert within three minutes of a genuine outage.
What timeout should I set for uptime monitoring?
Set your timeout slightly above your site's 95th percentile response time under normal load. If your API typically responds in 400ms but occasionally hits 1.2 seconds during traffic spikes, a 2-second timeout is reasonable. A 500ms timeout will generate false alerts every time your site gets busy.
What is alert flapping in uptime monitoring?
Flapping is when a monitor rapidly alternates between up and down states, sending a burst of alerts for a single underlying issue. It usually happens when your site hovers right at the edge of a timeout threshold or when a single probe has an unstable network path. Consecutive-failure thresholds and slightly relaxed timeouts reduce flapping significantly.
Should I monitor the homepage or specific API endpoints?
Monitor both, but treat them differently. Your homepage might load fine while your checkout API is broken. Set up separate monitors for critical endpoints like login, payment, and health check routes. Each monitor can have its own timeout and alert rules tuned to that endpoint's normal behavior.
Noisy alerts are worse than no alerts because they train your team to ignore monitoring entirely. Overwatch gives you per-monitor timeout and interval controls, multi-channel alerting to Slack, Discord, Teams, and webhooks, and a CLI to test alert delivery before you need it. Tune your monitors once, then trust the signal. Get started free →