Monitor down, but my site is up
Why a healthy site can show as down or degraded — a firewall blocking the checker, a timeout that's too low, redirects, or a keyword mismatch — and how to fix each.
You can load your site in a browser, but Telescope reports it as down or degraded. This almost always means the checker sees something different from what you see. Here are the usual causes, most common first.
Check the error first
Open the monitor and read the latest check's error message. It tells you which case below you're in — a WAF block, a timeout, an unexpected status code, or a keyword that wasn't found.
A firewall or WAF is blocking the checker
Why it happens. Cloudflare, Sucuri, AWS WAF, Akamai, and similar services block automated requests. Your site is up — it's just refusing Telescope's request. When the checker detects a block (a challenge page, a 403, a 429, or blocking keywords like "access denied" in the response), it reports degraded rather than a false down, so you get the signal without a false outage.
How to fix. Allow Telescope's checker through your firewall.
Whitelist Telescope's twelve static IP addresses. This is the reliable fix and works with every provider.
If a monitor is still degraded after whitelisting, also allow the checker's User-Agent (Telescope-Uptime/2.0) — some firewalls filter on that independently of IP.
The WAF whitelisting guide has step-by-step instructions and the IP list for each provider.
The timeout is shorter than your site's real response time
Why it happens. Every HTTP check has a timeout. If your site takes longer than that to respond — a cold start, a heavy page, a slow upstream — the request is aborted and the check is marked down with a Timeout after …ms error, even though the page would have loaded eventually.
How to fix. Raise the monitor's timeout so it comfortably exceeds your slowest normal response. The default is 30 seconds; increase it for endpoints that are legitimately slow. If the site is genuinely slow only sometimes, a higher failure threshold also helps ride out the occasional blip.
The URL redirects, and the final page isn't what you expect
Why it happens. By default Telescope follows redirects and checks the page it lands on. Two things can trip this up:
- If you've turned off "follow redirects", the checker evaluates the redirect response itself. A
301/302counts as up by default — but if you've narrowed the expected status codes to just200, the redirect reads as down. - If the final URL after redirects returns an error or an unexpected status — a redirect to a login wall, a maintenance page, or an error page — that's a real failure the checker will report.
How to fix. Point the monitor at the final URL your site settles on (for example the https:// or www canonical host), or keep "follow redirects" on and make sure your expected status codes include whatever the destination returns.
A keyword monitor can't find its text
Why it happens. A keyword monitor loads the page and asserts specific text is present (or absent). It's down when the text isn't where it expects. The match is case-insensitive, but common reasons it fails:
- The text is rendered by JavaScript after load — the checker reads the raw HTML response, not a rendered page, so client-side content won't be there.
- The wording changed, or the phrase is split across HTML tags so it isn't a contiguous string in the source.
How to fix. Choose a keyword that appears in the page's raw HTML (view source to confirm), keep it short and stable, and make sure a contains check targets text that's really present — and a not_contains check targets text that's really absent.
For a page whose content only appears after JavaScript runs, a keyword monitor won't see it. Use it on server-rendered markup, or watch that flow with a different check type.
Troubleshooting
The questions we hear most — why a healthy site shows as down, why an alert didn't fire, and what SSL and domain statuses mean — and how to resolve each.
Statuses and alert timing
What up, down, and degraded mean, and why an alert fires only after several failed checks in a row instead of the first one.