Important Notice! This website is currently running in a pre-launch testing phase, expected to continue until January 31, 2026. During this period the system is fully operational and user registration is available; however, some content, pages or features may still be incomplete or subject to change. Paid subscription plans will only become active once the platform officially launches in its final production version.
False alerts in uptime monitoring

False alerts in uptime monitoring: the most common causes

Created on 13 December, 2025Troubleshooting • 13 views • 1 minutes read

Short down alerts that recover in 1–2 minutes are often false positives: the site is up, but checks fail briefly due to temporary routing, WAF, or timeouts.



1) Slow responses / temporary overload

Dynamic sites (PHP + MySQL, heavy plugins, background jobs, cache misses) can occasionally respond too slowly. If your monitor uses a short timeout (for example 5 seconds), a single slow response may be recorded as “Unknown” or “Down”, while the next check returns HTTP 200.


2) WAF / Cloudflare / bot protection or rate limits

Security layers sometimes treat monitoring checks as automated traffic and may block or challenge them. This can result in:

  1. HTTP 403 Forbidden
  2. HTTP 429 Too Many Requests
  3. connection drops or timeouts that show up as “Unknown”

This is especially common when the block happens only from a specific monitoring node IP.


3) TLS handshake hiccups on shared hosting

On shared servers you may occasionally see short issues during:

  1. TLS handshake
  2. OCSP checks
  3. SNI routing


When this happens, the monitor may fail before it receives an HTTP status code, so the incident is logged as “Unknown”.


4) Location-specific routing problems

Sometimes only one region/node experiences packet loss or unstable routing (peering issues). In that case the website isn’t actually down — only the path from that monitoring location is. Multi-location confirmation or a different node selection usually resolves this.



Quick fixes checklist

If you’re getting short “down” alerts that recover quickly, try these steps first:

  1. Increase the request timeout to 10–15 seconds for dynamic sites (PHP/MySQL, CMS, web apps).
  2. Enable double-check / retry so a single failed request doesn’t trigger an incident immediately.
  3. Use multiple locations and confirm downtime only if more than one region fails.
  4. Set a browser-like User-Agent to reduce false blocks from WAF/CDN protection.
  5. Disable cache buster during troubleshooting (it can increase load and trigger security rules).
  6. Monitor a simple health URL (e.g., /uptime.txt returning OK) instead of the homepage.
  7. Check your logs when an alert happens (WAF events, rate limits, TLS errors, server load) to identify the real cause.
  8. Whitelist monitoring IPs in your firewall/WAF if you control it and you’re seeing repeated 403/429 responses.

This checklist usually eliminates most false positives without reducing real outage detection.