If a monitor is showing as down, this guide explains how UptimeRobot actually decides that — the retry rules, timeouts, and default request settings behind every check — so you can match your situation to a likely cause instead of guessing.
How a DOWN status is confirmed
A monitor isn't marked down after a single failed check. Depending on the type of failure, UptimeRobot retries first:
Connection failures (timeout, DNS failure, connection refused, TLS error) retry up to 3 times, 20 seconds apart.
Application failures (an HTTP status code outside your success list, or a keyword mismatch) retry up to 3 times, 10 seconds apart.
Only after those retries are exhausted does the monitor flip to Down. Two exceptions: SSL certificate errors don't retry at all — they go straight to Down on the first failed check — and once a monitor is already Down, the next check doesn't get a retry allowance either; a single check result is enough to keep it Down or bring it back Up.
No "multiple locations agree" requirement
UptimeRobot checks your monitor from one location at a time, rotating in round-robin order through North America, Europe, Asia, and Oceania. There's no quorum — a single region's failed (and retried) check is enough to mark the monitor down. This matters if something is only broken from one part of the world: a firewall, WAF, or CDN rule scoped to a specific country or region can make a monitor look down globally when it's really only unreachable from wherever that check happened to run.
Timeouts and what counts as "up"
The default request timeout is 30 seconds, and you can set it anywhere from 1 to 60 seconds in the monitor's settings. This is a single budget covering DNS lookup, connection, TLS handshake, and waiting for a response — there's no separate timeout for each step, so a slow DNS lookup uses up the same budget as a slow server response.
By default, any HTTP 2xx or 3xx response counts as "up," unless you've customized the accepted status codes for the monitor.
Default User-Agent
Unless you've set a custom one, UptimeRobot's checks send this User-Agent:
Mozilla/5.0+(compatible; UptimeRobot/2.0; http://www.uptimerobot.com/)
If your server, WAF, or bot-protection service allowlists by User-Agent, add this string exactly as shown (including the + right after Mozilla/5.0).
Down for you, but the site loads fine when you check it
This is almost always a difference in how your server treats an automated request versus a browser request. Common causes:
IPs not whitelisted. Make sure our checking IPs are allowed both on your server and by anything in front of it — CDN, WAF, hosting firewall. Find the list here: UptimeRobot Locations.
WAF or bot protection challenging the request. Services like Cloudflare can serve a CAPTCHA or block page to automated clients. Check your WAF/bot-protection logs for our User-Agent or IPs being challenged, and allowlist them.
Geo-blocking. If you block or restrict traffic from specific countries, remember checks run from North America, Europe, Asia, and Oceania — a rule that blocks one of those regions will cause real downtime reports from there.
Request method sensitivity. HTTP monitors default to a HEAD request, switching to GET automatically on a retry. Some servers reject HEAD outright (403/404/405), so every retry fails the same way and reads as a real outage. Try switching the request method to GET yourself under the monitor's Advanced Settings.
Down only sometimes (flapping)
If a monitor keeps flipping between Up and Down, the round-robin regions are the first thing to check: if checks happen to run from a region where your server or CDN edge is misconfigured while it's fine elsewhere, downtime will only surface when that region comes up in rotation, and it can look intermittent. Open the incident log for each downtime event to see which region reported it, and look for a pattern.
Because a DOWN only fires after retries (20 seconds apart for connection failures, 10 seconds apart for application failures), one-off blips are usually filtered out on their own — repeated short downtimes are more often a real, recurring issue on your end (restarts, autoscaling, rate limiting) than monitoring noise.
Timeout errors
If an incident shows a timeout, your server (or something in front of it) isn't responding within your monitor's configured timeout window — 1 to 60 seconds, 30 by default. Check your server's actual response time under load, and consider raising the timeout if it's reliably just slow rather than genuinely down.
Ping (ICMP) and firewall-specific issues
Ping monitors depend on ICMP echo requests, which many cloud providers, firewalls, and network appliances block by default. Confirm ICMP traffic is explicitly allowed from our IPs, in addition to whitelisting them for HTTP(S) traffic.
Other things to check
Check the incident log. Each incident records the specific error code and timestamp — this is the fastest way to confirm what actually happened.
Check your server logs. Look for HTTP 500s or other server-side errors around the time of the incident.
Test the URL manually from a browser, or with a tool like Down For Everyone Or Just Me, to rule out a widespread outage.
Double-check the monitor's configuration — URL, port, and other settings should match what you're actually monitoring.
Pause and restart the monitor. This clears any stuck state and forces a fresh check.
If you've worked through this and the monitor is still showing down incorrectly, contact our support team with the incident log details.