Is it better to get a false alarm than to miss an outage?

Within reason, yes, but false alarms have a real cost. When alerts are often wrong, people start ignoring them, and the real outage gets the same shrug. Fix the cause of each false alarm instead of muting the monitor.

Should I just increase the number of failed checks before alerting?

Requiring two or three consecutive failures reduces noise but delays every real alert by one or two check intervals. Confirming the failure from a second location right away removes most noise with far less delay.

Why does my monitor say the site is down when it loads fine for me?

Your browser and the monitor take different paths. The monitor may be blocked by a firewall or bot filter, hitting a different server or region, or timing out on a slow first byte that your browser hides with a spinner. Fetch the page with curl from another network to see what the monitor sees.

Can I allowlist an uptime monitor by IP address?

Only if the monitoring service publishes a fixed list of IP addresses. Many services run on cloud or edge networks with changing addresses, in which case allowlisting by user agent or by a dedicated health-check path is the practical option.

How to Avoid False Downtime Alerts

False downtime alerts usually come from one failed check that did not reflect what users experienced. The common causes are short network blips between one monitoring location and your server, timeouts set too close to normal response times, firewalls and bot protection that block the monitor, rate limits, DNS changes still propagating, and keyword checks that break when content changes. The fixes are: confirm failures from a second location, give requests a realistic timeout, let your monitor through your security rules, and pick keywords that only disappear when the page is truly broken.

Why false alarms matter

An alert that is wrong once a week trains everyone to wait and see. Then a real outage arrives, and the first response is "probably the monitor again." Noise also tempts people into bad fixes: longer check intervals, higher failure thresholds or muting the monitor entirely, which all make real outages slower to detect.

The aim is not zero alerts. It is that every alert is worth acting on.

Cause 1: A blip at one location

The internet between one monitoring location and your server is many networks. A congested link, a routing change or a short packet-loss event can make one request fail while users everywhere else are fine. Your server never saw a problem, because the request never arrived.

Fix: confirm from a second location. When a check fails, re-run it immediately from a different region. Only alert if the second check also fails. A local network problem rarely hits two distant paths at the same moment, while a real outage fails both.

This is better than simply requiring several consecutive failures from the same location, because:

Approach	Removes blips	Extra delay on real outages
Alert on first failure	No	None
Require 2-3 consecutive failures	Mostly	One or two full check intervals
Confirm from a second location	Mostly	A few seconds

Consecutive-failure thresholds still have a place for checks that are naturally flaky, but they should not be your only defense.

Cause 2: Timeouts that are too tight

If your homepage usually responds in 600 ms but sometimes takes 4 seconds after a cache clear or a cold start, a 3-second timeout will alert on a page that was slow but working.

Fix: set the timeout from real data. Look at your response-time history and set the timeout well above the slow end of normal, for example three to five times the usual worst case. For most websites, somewhere in the 10 to 30 second range is sensible. Users notice slowness long before that, but a timeout is meant to separate "slow" from "not responding," not to measure performance.

Check the time to first byte yourself:

curl -o /dev/null -s -w "dns %{time_namelookup}s  connect %{time_connect}s  tls %{time_appconnect}s  first byte %{time_starttransfer}s  total %{time_total}s\n" https://example.com/

Run it several times. If the first request is slow and later ones are fast, you are seeing a cold cache or a sleeping server, and you should decide whether that slowness is itself the problem. If slowness is a genuine concern, treat it as a performance issue with its own measurements rather than tightening the uptime timeout. The 504 Gateway Timeout guide covers the server-side causes.

Cause 3: Firewalls, WAFs and bot protection

Security tools are designed to block automated traffic, and an uptime monitor is automated traffic. Depending on the product and settings, the monitor may get:

a 403 Forbidden,
a 429 Too Many Requests,
a JavaScript or CAPTCHA challenge page returned with a 200 or 503 status,
a connection that is dropped or reset.

The pattern is easy to spot: the monitor reports failures, but the site works in your browser. Often it starts right after enabling a new security feature or raising a protection level.

Fixes:

Allow the monitor by user agent. Most monitoring services send a recognizable User-Agent header. Create an allow or skip rule in your WAF or bot-protection settings that matches it, scoped to the paths you monitor.
Allow by IP only if the service publishes fixed addresses. Many services run on cloud or edge networks whose addresses change, so an IP allowlist goes stale.
Monitor a dedicated health path. A /health or /status route that returns a small response can be excluded from challenge rules without exposing the rest of the site.
Watch for challenge pages. If you use a keyword monitor, a challenge page will fail the keyword check, which is useful: it tells you the monitor is being blocked rather than letting a challenge page pass as "up."

Test what the monitor sees by sending the same user agent:

curl -sI -A "YourMonitor/1.0" https://example.com/

Matching by user agent is not a security control, since anyone can send any header. Keep the rule narrow: only the monitored paths, only GET requests.

Cause 4: Rate limits

Rate limiting protects your server, but monitors from several locations, checking several URLs each, add up. If they share a rate-limit bucket with other automated traffic, or if a page triggers a stricter limit, some checks will get a 429.

Fixes: exempt the monitor's user agent or health path from the rate limit, monitor fewer heavy pages and more lightweight ones, and check that your limits are counted per client rather than across all traffic. The Retry-After header on a 429 tells you how long the limiter wants clients to wait, which is a clue to which rule is firing.

Cause 5: DNS changes and caching

When you change DNS records, resolvers keep the old answer until its TTL expires. During that window, the monitor and your browser can resolve the name to different servers. If the old server is already switched off, the monitor reports downtime that you cannot reproduce, or the reverse.

Fixes:

Lower the record's TTL a day before a planned change, then raise it again afterwards.
Keep the old server running, or redirecting, until the old TTL has passed.
Compare what different resolvers return:

dig +short example.com A @1.1.1.1
dig +short example.com A @8.8.8.8

A DNS failure where the name does not resolve at all is usually a real problem, not a false positive. Expired domains and deleted records belong in that category.

Cause 6: Keyword checks that are too fragile

A keyword monitor fails when the expected text is missing. If the keyword is a price, a date, a promotional headline or text that is translated or A/B tested, it will disappear during normal content changes.

Fix: choose text that only disappears when the page is broken. Good keywords are generated by the application, appear in the server's HTML rather than after JavaScript runs, and do not change with marketing. Labels such as an add-to-cart button, a navigation item loaded from your CMS, or "status":"ok" in a health response work well. Also keep the keyword near the top of the HTML: some monitors only read the first part of a large page.

Cause 7: Your own planned work

Deploys, restarts and maintenance cause real downtime that you already know about. Alerts for it are technically correct but still noise. Pause the affected monitors before the work and resume them after, and tell users through your status page. If deploys regularly cause a few seconds of errors, consider a zero-downtime deploy strategy instead of tolerating the alerts.

A quick triage routine for "the monitor says down, the site is up"

Read the error the monitor recorded: timeout, connection error, status code or missing keyword. Each points to a different cause above.
Fetch the URL with curl from a network other than your office or home, using the monitor's user agent.
Check your WAF, bot protection and rate-limit logs for blocked requests at the alert time.
Compare DNS answers if you recently changed records.
Look at your server logs: if the request never arrived, it was a network or security-layer problem; if it arrived and was slow, it was a timeout.

Settings that keep alerts trustworthy

PingRobot re-checks every failure from a second region before sending an alert, lets you set the request timeout per monitor (5, 10, 15 or 30 seconds; 15 by default) and an alert delay, so an outage has to last a few minutes before anyone is paged, and identifies itself with the user agent PingRobot/1.0 (+https://pingrobot.io/bot), which you can allow in your WAF rules. For the basics of how checks work, see what is uptime monitoring.

Start monitoring free — 10 monitors, no credit card.