Why a monitor is down when your site works

An incident only opens after two checks in a row fail: the failed check is repeated from another location, or from Stockholm 10 seconds later while that is the only one. So when the site still works for you, our check and your browser are seeing different things. The incident shows what the check saw.

Start with the evidence

Open the incident from Incidents. What we saw lists each failed check with its error. For websites it also shows:

• Connected to and Resolved to: the IP address we reached, and what DNS answered.
• Redirected to, the Certificate, and Headers such as Server, CF-Ray and Retry-After.
• Start of the response: the first 2 kB the server sent. A block page or an error message shows up here.
• A screenshot when the server answered, or the network path (a traceroute) when it didn’t.

The screenshot is taken by a real browser on another network. If it looks fine while the check failed, something treats our checks differently, often a firewall rule.

Common causes

• A firewall or bot protection answers HTTP 403, HTTP 429 or a challenge page such as Cloudflare’s “Just a moment…”. Your browser passes; a check can’t solve a challenge. Allow Uptimecheck through the firewall.
• The keyword isn’t in the page. Keywords are case-sensitive and matched in the HTML the server sends, so text that JavaScript adds later isn’t there. Pick a word from the page source, or use a flow in a real browser.
• Redirects: the check follows up to 10 and judges the last page, so a redirect to a login page, a cookie wall or another country’s site can fail a keyword. More than 10 gives Too many redirects.
• The status code: by default 200 to 399 counts as up. A page that is meant to answer 401, behind a login, needs that code in Expected status codes.
• The certificate: an expired or self-signed certificate, or one for another host name, marks the monitor down while Verify TLS certificate is on. A missing intermediate certificate doesn’t: browsers download it, and so does our check, but the monitor shows Incomplete chain, since some apps and older devices can’t.
• DNS: after a move, resolvers keep the old answer until its TTL runs out, so we may reach the old server while you reach the new one, or the other way round. Compare Connected to with your server’s address. A name that only resolves inside your network can’t be checked from outside, and one that resolves to a private address is refused.
• Timeouts: a check waits 10 seconds by default (Timeout (s)). Your browser may show a cached copy, or one from a CDN near you, while the server itself is slow.
• Location: checks run from Stockholm, Sweden. A site that blocks visitors from outside its country, or a network fault between Stockholm and your host, fails for us and not for you. The network path shows where packets stop.
• Your own access: an allowed office IP address, a VPN, a logged-in session or a hosts file entry can make the site work for you alone.

When the problem is ours

If the network of one of our locations has trouble, most of the well-known sites we check from it fail at once. We watch for that and hold back incidents from that location, so you aren’t alerted about our problem.

Check it yourself

Edit the monitor and use Test request to send one request from our servers and see the answer. Once the cause is fixed, two passing checks in a row close the incident. See how incidents and evidence work, and how to reduce false alerts.