Uptime monitoring

Let our uptime checks reach your site

Glow checks whether your sites are online from outside, the same way a visitor arrives. If a site sits behind a firewall, a WAF or a bot protection service, those checks can be refused before they reach your server.

When that happens we will not call the site down, because we cannot prove it is. We tell you we cannot verify it instead. This page is how to fix that.

What our checks look like

18.171.1.94

A plain HTTPS GET of your home page, with the user agent GlowMonitor/1.0 (+https://getglow.io/monitor). We read the response headers and stop, so we never download your pages. Frequency follows the check interval set for the site, as often as once every three minutes.

This IP list can grow as we add monitoring locations. Allowlisting the GlowMonitor user agent instead keeps working when it does.

First, check what your site does

Open the site in a browser. If it loads for you but Glow cannot verify it, the site is fine and this is a monitoring problem. Run the same request we run to see what we see. Note this is a GET rather than curl -I: a HEAD request can answer 200 on a site whose real pages are returning an error, so it will tell you everything is fine when it is not.

curl -sS -o /dev/null -w "%{http_code}\n" -A "GlowMonitor/1.0 (+https://getglow.io/monitor)" https://your-site.com

200, 301 or 302: we can see the site, and any alert you had is about something else.

500, 502, 503 or 504: the server answered, but with an error. The page often still renders normally in a browser, so this looks like a false alarm and is not one: anything reading the status, including search engines, sees the error. Worth checking with a query string on the end, such as ?test=1: if that returns 200 and the plain address does not, something is serving a cached error page.

401, 403 or 429: your site is refusing us. The two sections below cover the two reasons that happens, and they need different fixes.

No response at all: the request never completed, which is what a real outage looks like from here too.

Reason 1: something is blocking us by address

A server firewall, a security plugin or a rate limiter has our IP on a block or throttle list. Allowlisting fixes this one.

Cloudflare

Go to Security → WAF → Tools → IP Access Rules, add each IP above with the action Allow, scoped to the affected site. Or add a WAF custom rule that skips your challenge when http.user_agent contains "GlowMonitor".

Wordfence

Under Wordfence → Firewall → Blocking, and under Rate Limiting → Allowlisted IPs, add each IP so the firewall never blocks or throttles it.

Server firewall or host panel

Add each IP to your allow rules in cPanel, Plesk, Sucuri, or your hosting provider's own firewall, so HTTPS requests from them are never blocked.

Reason 2: bot protection is refusing anything that is not a browser

This one is different, and it is the more common of the two on managed WordPress hosting. Services like Cloudflare Bot Fight Mode, and the edge protection built into hosts such as Kinsta, WP Engine and Sucuri, do not decide by IP address or user agent. They look at how the connection itself is made and expect a real browser running JavaScript.

Allowlisting an IP address does not fix this. Neither does allowing the user agent, on plans where the bot rules run before your own rules do. You can spot it easily: the site returns 403 to the curl command above from any machine, including your own, while it loads perfectly in your browser.

On Cloudflare

With Super Bot Fight Mode (Pro and above), add a WAF custom rule with the Skip action matching http.user_agent contains "GlowMonitor", and set it to skip Super Bot Fight Mode. Plain Bot Fight Mode on the free plan cannot be skipped by a rule: turn it off for the site, or use the plugin route below.

On managed hosting

Kinsta, WP Engine, Sucuri and similar run this protection at their own edge, in front of anything you control. Ask their support to add an exception for the GlowMonitor user agent and the IPs above, quoting uptime monitoring as the reason.

The shortcut: connect the Glow plugin

A site running the connected Glow plugin reports in from the inside. That is proof the site is alive that no firewall can block, so we can confirm uptime even when our external check is being refused, and you do not have to get an exception out of anybody.

If Glow cannot verify a site, it is worth checking the plugin is installed, connected, and that WordPress cron is running on it. External checks still give the most accurate picture, so it is worth doing both where you can.

What "cannot verify" means

When a site refuses our checks we hold off calling it down. A refusal means your server answered us, so something is running, and reporting an outage we cannot prove would be worse than saying nothing.

If that carries on for more than a day, and the site has never reported in through the plugin either, we email you to say we cannot verify it. That email is not a downtime alert. It means one of the two blocks above is in the way, or the site is closed to visitors as well, in which case they are seeing the same refusal we are.

Still stuck after allowlisting? Send us the site address and the output of the curl command above and we will tell you what our checkers are seeing.