A website down alert from us means our uptime monitor loaded the site and didn't get what it expected. It doesn't always mean visitors can't reach it. We monitor every site on our platform, and each check asks two questions: did the page return a success status, and does it contain a piece of text we know belongs on that site? If either answer is no, you get an alert. This guide explains what the monitor saw, the common reasons a site that looks fine to you still fails the check, and what to do about each one.
When a check fails, our system opens a support ticket and emails you. The subject reads We're looking into an outage on example.com. That first email is a heads-up. We're already looking, and you don't need to do anything yet.
When the site passes the check again, we post a second reply on the same ticket: example.com is back up as of 3:01 PM ET. It was down for about 20 minutes. That reply is automatic. It reports when the check started passing again, so if a site sat in maintenance mode for three days, the "back up" email arrives three days later and says it was down the whole time.
[SCREENSHOT: the "We're looking into an outage" email as a member receives it in their inbox, with the domain replaced by example.com and the member's name removed. Highlight the subject line. Why: readers search for the exact email they got.]
Every check loads the site's home page over HTTPS and looks at two things:
| Check | Passes when | Fails when |
|---|---|---|
| Status code | The page returns a 2xx status, such as 200. |
Any other final status: 500, 503, 403, 404, or no answer at all. |
| Keyword | A piece of text from the site, usually the site or business name, is on the page. | The text is missing, for example because a different page is being served. |
The keyword check is the part that catches problems a plain "is it up?" test misses. A parked domain page, another host's default page, or a redirect to a different site all return 200, but none of them contain your site's name.
Our monitor runs from the United States.
These are the causes we've seen most often, roughly in order. The second column tells you whether visitors were affected.
| What the monitor saw | Were visitors affected? | Typical cause |
|---|---|---|
503 and a "Maintenance Mode" or "Coming Soon" page |
Yes, by design | A maintenance mode plugin or page builder setting is on. |
A 503 block page from a security plugin |
No | Wordfence or another firewall blocked our monitor. |
| A page without the keyword, from a different server | Yes | DNS points at another host, or the site launched and the old host still answers. |
| A redirect to a different site | Yes | A redirect rule at Cloudflare or the registrar sends the domain elsewhere. |
A 500 with "There has been a critical error on this website" |
Yes | A PHP fatal error in WordPress. This one is real. |
| A timeout for a few minutes, then back up | Maybe | A slow request, or a network problem between our monitor and the server. |
Maintenance mode plugins, and the maintenance mode setting in page builders like Elementor, serve a page with HTTP status 503 Service Unavailable. That's the correct behavior: it tells search engines and monitors the site is temporarily unavailable. Our monitor counts it as down, because to a visitor it is.
If you put a site in maintenance mode on purpose, for example while building a new site, reply to the alert and tell us. We'll adjust monitoring for that site while you work, so you don't get an alert for every check.
If Wordfence or a similar firewall blocks the network our monitor runs from, the monitor gets a block page instead of your site. Everyone else gets the site normally. You'll see the block in the plugin's blocking list, often as a manual block.
Reply to the alert and we'll give you the IP address to add to the plugin's allowlist. Once it's allowed, the monitor picks the site back up on its own.
This is the most common cause of a real outage that isn't on our server. Our server is serving the site, but the domain sends visitors somewhere else. We've seen:
ns1.wpcdns.com and ns2.wpcdns.com, for domains that use our DNS) brought the site back.The site may look fine to you because your computer still has the old DNS answer cached, or because you have a hosts-file entry from testing. Check what the rest of the internet sees.
Without the terminal: enter your domain in a public DNS lookup tool such as whatsmydns.net or MXToolbox, and look up the NS (nameserver) and A (server address) records. If the nameservers aren't ours, or the A record isn't your site's server, that's the cause. If your domain uses our DNS, you can also open Zone Editor in cPanel (under Domains) and compare the A record there with what the lookup tool shows. If the two differ, DNS is hosted somewhere else.
With the terminal:
dig NS example.com +short
dig A example.com @1.1.1.1 +short
Then follow WordPress white screen or site down? Check domain and DNS to find where the DNS is hosted and fix it. Nameserver changes you didn't make are worth taking seriously: change the registrar account password, turn on two-factor authentication, and ask the registrar's support who made the change.
Redirect rules at Cloudflare, or URL forwarding at the registrar, run before a request ever reaches our server. If one sends the whole domain to another site, such as a shop on another platform, every visitor goes there. The monitor follows the redirect, doesn't find your site's text, and reports the site as down.
If the redirect is intentional because the site is retired, reply to the alert and tell us so we can update monitoring. If it isn't, check Rules in the domain's Cloudflare dashboard, or the registrar's forwarding settings.
Sometimes the alert is exactly what it says. A 500 status with There has been a critical error on this website is a PHP fatal error, usually from a plugin update or a PHP version change. See There has been a critical error on this website: how to fix.
The site may still look fine to you because LiteSpeed Cache is serving you a saved copy, or because you're logged in to wp-admin, where pages aren't cached. Test logged out, in a private window, and add a made-up query string to the address, such as https://example.com/?nocache=1, so the browser asks for a fresh copy. If you'd rather use the terminal:
curl -s -o /dev/null -w '%{http_code}\n' "https://example.com/?nocache=$(date +%s)"
A site can fail a check for a few minutes when one request takes too long, for example during a heavy backup or a slow call to an outside service. Distance can add to it: our monitor runs from the US, so a site served from a data center on the other side of the world has less time to spare. One short alert that clears on its own is rarely worth chasing. If it happens again and again, tell us and we'll look at the server side.
200 or 503) and a DNS lookup tool like whatsmydns.net (it shows where the domain points). If you're comfortable in a terminal, these two commands show the same thing:bash
curl -sI https://example.com/ | head -n 1
dig A example.com @1.1.1.1 +short
You don't have to diagnose it yourself. If you reply "not sure," we'll tell you what we found.
If you're building a site and don't want alerts yet, reply to the alert or open a ticket and tell us. We can adjust monitoring for one site or exclude it, or exclude every site on your account. The tradeoff is simple: if an excluded site goes down, we won't know until you tell us. Most agencies leave monitoring on and just let us know when a site is in maintenance mode or about to launch.
Also tell us when a site's name or main text changes, for example after a rebrand or redesign. The keyword we check for comes from the site, so we'll update it.
Contact us if:
Reply on the alert ticket, or see Need Help? for other ways to reach us.
Usually not. Several alerts across different sites in a short period usually have several unrelated causes: a site in maintenance mode, a DNS change, a firewall rule. We look at each one. If something were wrong with the server or your account, we'd tell you directly.
The monitor reports from the first failed check to the first successful one. A site that stayed in maintenance mode, or on another host's DNS, for three days shows as down for three days, even if you knew about it.
No. The first email means we're looking. Check the site if you want to, and reply if you know why it's down. Otherwise we'll update the ticket.
Yes. Ask us and we'll exclude the site or your whole account. We'd rather adjust it than turn it off, because an excluded site that goes down won't trigger an alert.