Back to Blog
How to Manage False Positives and Whitelist IPs in UptimeRobot
·UptimePulse Team

How to Manage False Positives and Whitelist IPs in UptimeRobot

Stop alert fatigue caused by false positives in UptimeRobot. Learn how to whitelist IPs, configure notifications, and fine-tune your monitoring.

uptimerobotfalse positiveswhitelistingalert fatigue

UptimeRobot is one of the most popular free website monitoring tools, but false positives are its Achilles' heel. When your phone buzzes for an outage that isn't real, you start ignoring alerts — and that's exactly when a real outage catches you off guard.

Why False Positives Happen

False positives in UptimeRobot typically occur because:

  1. Network blips — temporary routing issues between the monitoring server and your site
  2. Firewall blocking — your security rules blocking the monitoring IP
  3. CDN edge cases — cached content returning errors while origin is fine
  4. DNS propagation — monitoring checks hitting stale DNS records
  5. Rate limiting — your server throttling requests from the monitoring IP

Understanding the root cause is the first step to eliminating them.

How to Whitelist UptimeRobot IPs

If your firewall is blocking UptimeRobot, the simplest fix is whitelisting their IPs. Here's how:

Step 1: Get UptimeRobot's IP Addresses

UptimeRobot uses these IP ranges for monitoring checks:

  • 69.162.252.0/24 (US locations)
  • 162.244.52.0/24 (EU locations)
  • 198.51.100.0/24 (additional range)

Check their official documentation for the most current list.

Step 2: Add to Your Firewall

For iptables:

# Allow UptimeRobot US range
sudo iptables -A INPUT -s 69.162.252.0/24 -j ACCEPT

# Allow UptimeRobot EU range
sudo iptables -A INPUT -s 162.244.52.0/24 -j ACCEPT

For Cloudflare:

  • Go to Security > WAF > IP Access Rules
  • Add each UptimeRobot IP range with action "Allow"

For AWS Security Groups:

  • Add inbound rules for each IP range on ports 80 and 443

Step 3: Verify the Whitelist

After adding the IPs, test from UptimeRobot's dashboard. Force a manual check and confirm it succeeds.

Fine-Tuning Alert Thresholds

Whitelisting helps, but you also need smarter alerting:

Increase Retry Count

By default, UptimeRobot retries once before alerting. Increase this to 2-3 retries to filter out transient network issues:

  1. Go to Monitor Settings
  2. Click Alert Contacts
  3. Set "Retries Before Alert" to 2 or 3

Adjust Monitoring Intervals

Longer intervals mean fewer false positives but slower detection:

  • Homepage: 5 minutes (acceptable for most sites)
  • API endpoints: 3-5 minutes
  • Critical services: 1-2 minutes (requires paid plan)

Use Maintenance Windows

Schedule maintenance windows for planned downtime. UptimeRobot won't alert during these periods:

  1. Go to My Settings > Maintenance
  2. Set recurring or one-time windows
  3. Configure which monitors are affected

Advanced: Filtering False Positives

Response Code Filtering

If your monitoring alerts on 5xx errors but your server occasionally returns 503 during high load, adjust the alert conditions:

  • Only alert on specific error codes (500, 502, 504)
  • Ignore timeout alerts if your server is slow but responding

Keyword Monitoring

Instead of just checking if the page loads, check for specific content:

  • Monitor for "Database connected" or "API healthy" text
  • Avoid false positives from error pages that load with 200 status

Custom HTTP Headers

Some monitoring issues come from missing headers. Ensure your server returns:

  • Proper Content-Type headers
  • Correct Cache-Control for dynamic content
  • Appropriate Connection: keep-alive

When to Consider Alternatives

UptimeRobot's free tier is great for basic monitoring, but false positives become harder to manage as you scale. Consider alternatives if:

  • You need smarter anomaly detection
  • You want automatic false positive suppression
  • You need faster check intervals without paying premium prices
  • You want a cleaner, more modern interface

The UptimePulse Approach

UptimePulse was designed to eliminate false positives from the start. Our ML-powered baselines learn what "normal" looks like for your specific services, so we only alert on genuine anomalies — not routine traffic patterns.

Instead of static thresholds that trigger on every spike, our system understands that a 200ms latency increase during peak hours is normal, but the same increase at 3am is suspicious.