Product
Solutions
Compare
Resources
Get early access Talk to us
Uptime monitoring

WordPress uptime monitoring that only alerts you when a site is really down

WPCentrify checks every WordPress site you manage the way a visitor would, from 3 locations in Malaysia, Canada and the USA. If people cannot see and read your site, you get an email. If they can, it stays quiet.

Included on every plan. No add-on pricing.

Updated

WPCentrify uptime monitoring map with checks from Malaysia, Canada and the USA, each reporting the site as up, and a status card showing the site confirmed up from all three locations
One site, 3 locations. Each site is checked from Malaysia, Canada and the USA, as often as every 60 seconds.

What is WordPress uptime monitoring?

WordPress uptime monitoring is a service outside your site that loads it on a schedule, checks that a visitor would get a working page, and alerts you when they would not. It has to run from outside on purpose: a plugin inside a broken WordPress site cannot report that the site is broken.

WPCentrify does this for every WordPress site you connect, from one dashboard. It does not stop at the status code. It reads the page the way a visitor would, so a WordPress critical error, a database connection error or a suspended hosting account counts as down even when the server says all is well. It also knows what is not an outage, such as WordPress updating itself or a firewall turning away only our checker, so those never reach your inbox. New to the topic? Our guide to website uptime monitoring explains checks, intervals and uptime percentages with no vendor pitch, and our comparison of website uptime monitoring software sets nine tools side by side.

WPCentrify uptime monitoring at a glance

  • Every site is checked from 3 locations: Malaysia, Canada and the USA.
  • Checks run as often as every 60 seconds, depending on your plan. Once a check fails, the site is checked every minute on every plan until the result is certain.
  • A site counts as down when a visitor would not get it: no answer within 20 seconds, a server or Cloudflare error, a WordPress critical error or database error, a suspended hosting account, a broken SSL certificate, a domain that no longer exists, or a maintenance page still up after 12 minutes.
  • An email goes out only when locations on different providers agree, after three failed checks in a row by default.
  • On sites checked every minute, the email usually arrives 2 to 3 minutes after the site goes down.
  • A website down email, a few reminders while it stays down (at most 4 emails per outage) and a back up email when it works again.
  • The same place warns you about an unreachable wp-admin, a disconnected WPCentrify plugin, an expiring domain and an expiring SSL certificate.
  • Alerts go by email, the one alert channel for now.
The problem

Why do basic uptime monitors get WordPress wrong?

A false alarm at 3am is worse than useless: it teaches you to ignore the next one. A missed outage is worse still.

Most WordPress outages are not dramatic server failures. They are a database that stops answering, a plugin update that ends in a critical error, an SSL certificate that ran out or a hosting account suspended over an unpaid invoice. Many of those error pages come back with a normal 200 status code, so a monitor that reads only the status code calls the site healthy while visitors read an error.

The opposite mistake is just as common. A security plugin or a Cloudflare challenge turns the checker away, a network blip hits the one place it checks from, or WordPress shows its own maintenance page for a few seconds during an update. A basic monitor treats all of that as an outage. When a site does go down for real, the WordPress site down checklist works through the causes in order.

How WPCentrify uptime monitoring compares with a basic status code monitor
SituationBasic monitorWPCentrify
The page says "Error establishing a database connection" but the server sends a 200 statusUpDown
Your host's "This Account has been suspended" page is served with a 200 statusUpDown
A security plugin or a Cloudflare challenge turns away only the checkerDownNot down, no email
WordPress shows "Briefly unavailable for scheduled maintenance" during an updateDownNot down, unless it is still there after 12 minutes
A network problem near the one place the checker runs fromDownNot down: locations on different providers must agree

A basic monitor here means one that reads only the status code from a single location, the simplest check most uptime tools offer.

What counts as down

What counts as downtime for a WordPress site?

WPCentrify calls a WordPress site down when a visitor would get one of these instead of your homepage.

What WPCentrify counts as downtime for a WordPress site
What the visitor getsWhat WPCentrify looks for
No answer from the serverThe connection is refused, the server cannot be reached, or nothing comes back within 20 seconds.
A server errorErrors such as 500 Internal Server Error, 502 Bad Gateway and 504 Gateway Timeout.
A Cloudflare error pageCloudflare saying your server let it down: errors 520 to 526 and 530, for example 521 Web server is down, 522 Connection timed out and 524 A timeout occurred.
A broken WordPress site"There has been a critical error on this website.", "Error establishing a database connection." or a PHP fatal error printed where the page should be. Caught even when the server labels the error as a normal page, which many hosts do.
Hosting that is gone or not set upThe host's "This Account has been suspended" page, or a bare server page instead of your site: "Welcome to nginx!", Apache's "It works!", an "Index of /" file listing or a hosting panel's default page.
A browser security warningAn SSL certificate that has expired, belongs to a different domain or is self-signed. Visitors get a full-screen warning instead of your site.
A domain that no longer existsConfirmed by a second, separate DNS service, so one DNS provider's bad minute is never enough.
A maintenance page that never goes awayWordPress shows a short maintenance page while it updates. If a maintenance page is still showing after 12 minutes, it counts as down.

The WordPress errors in this list are the ones a status code check misses most often. Our guides to the WordPress critical error and the white screen of death explain how to fix them once you know.

Fewer false alarms

What does WPCentrify deliberately not call down?

These look alarming to a basic monitor, but your visitors are fine, so no email is sent.

  • WordPress updating itself. The "Briefly unavailable for scheduled maintenance" page that appears while plugins, themes or WordPress update.
  • Work run from WPCentrify. No alert while an update or a restore you started from WPCentrify is in progress.
  • Firewalls and bot checks that block only our checker. Cloudflare challenges and blocks, Wordfence, Sucuri, Imunify360, ModSecurity, rate limits and password-protected sites. Your visitors still get in, so the site is not down.
  • A plain "Forbidden" or "Not found" with nothing else on the page. That is also how a firewall turns away just our checker, so we cannot be sure every visitor sees it.
  • A page that only mentions an error. For example, a help article that quotes "critical error".
  • An error further down a page that loaded. If visitors can see your site and the problem is lower on the page, it is not an outage.
  • A slow site that still loads. Slow is not down. Speed and Core Web Vitals belong to WordPress performance monitoring.
  • Problems on our side. If many sites fail at the same moment and outside reference sites are unreachable too, that is our network, not yours, and nothing is sent.
Multi-location monitoring

Checked from Malaysia, Canada and the USA

Each site is checked from 3 locations on three continents, run on more than one provider, as often as every 60 seconds.

Malaysia

Covers Asia and the Pacific, where a checker in North America cannot see what your visitors see.

Canada

A second view of North America, so a regional problem on one side of the continent is not mistaken for an outage.

USA

The view most of your visitors share, on the same check cycle as the other locations.

Why more than one provider matters

An uptime alert is only useful if you trust it. When one checker loses its route to your server, a single-location monitor reports the site as down even though every real visitor can reach it. WPCentrify treats that as noise.

A site is only reported down when locations on different providers agree, after three failed checks in a row by default. Locations on the same provider can share the same bad network day; different providers rarely do.

Diagram of WPCentrify multi-location uptime checks from 3 locations: when only Malaysia sees a failure there is no alert, and when Malaysia and Canada, on different providers, both see the site down, the outage is confirmed and an email is sent
How an alert is decided. One location failing is logged and ignored. Locations on different providers agreeing sends the email.
How it works

How does WPCentrify make sure a site is down before it emails you?

From the first failed check to the back up email, without anyone watching a screen.

  1. A check fails

    The site does not answer, returns an error or shows a broken page. Nothing is sent yet: one failed check is never enough.

  2. The site is checked every minute

    As soon as a check fails, that site is checked every minute, on every plan, until the result is certain.

  3. Blips get a second opinion

    A dropped connection, a timeout, a DNS hiccup or a bare "Service unavailable" is looked at again on a fresh connection, using a different DNS service. It only counts if the second look agrees.

  4. Locations on different providers agree

    By default it takes three failed checks in a row, seen from locations on different providers, before the site is marked down.

  5. You get one email in plain words

    It says what was seen, such as a Cloudflare 522 or a database connection error. On sites checked every minute it usually arrives 2 to 3 minutes after the site went down; on the slowest check interval, up to about 7 minutes.

  6. A back up email closes the outage

    As soon as checks confirm the site works again, you get a back up email, and the length of the outage counts toward the site's uptime figures and SLA.

Every check also opens a new connection, checks every address your domain points to and follows redirects the way a browser does, so each check sees the site the way a new visitor would.

Alerts

WordPress downtime alerts by email, only when they matter

When an outage is confirmed you get an email that says what was seen, in plain words. Failed checks that never became an outage stay in the record, not in your inbox.

  • A website down email, and a back up email as soon as the site works again
  • A few reminders while it stays down, with at most 4 emails per outage
  • Louder alerts where they matter: mark a site as taking payments, holding customer data or under a service agreement, and its reminders come twice as often with an urgent subject line
  • One email for a host-wide outage, listing every affected site, once you tell us who hosts each site
  • Choose who hears what: each kind of alert goes to the right people, for the right sites
  • Email is the one alert channel for now

An example alert. Sites and times are illustrative.

Beyond the homepage

What else can WPCentrify uptime monitoring alert you to?

Some problems leave the homepage working. These alerts live in the same place as uptime and arrive the same way.

Admin area unreachable

Your homepage works, but wp-admin is failing, so nobody can log in to fix anything.

WPCentrify plugin disconnected

The WPCentrify plugin on your site stopped reporting. The site may still be up, but you will want to know why.

Domain expiring

A warning 30 days before your domain registration runs out, and again in the final week, for most domain endings.

SSL certificate expiring or expired

An optional warning, switched on per alert profile, so visitors never meet a browser security warning.

The pages that matter

Watch a checkout, a booking form or a landing page as well as the homepage. The pages that earn money are the ones worth checking.

Pages behind a login

Check an account area or members page that anonymous visitors never see, so a broken login is caught even when the homepage looks fine.

A form that quietly stops sending is a silent failure too, which is why inquiries from every site are collected in one place.

After an outage

Uptime history, SLA tracking and status pages

Every outage leaves a record you can show a client.

Uptime history per site

A 24-hour bar for every site and uptime figures for your monthly reports. An hour when checks saw the site working counts as up; if there is no information about an hour, the record says so instead of guessing.

SLA tracking per client

If you promise 99.9 percent, WPCentrify measures each site against that number and warns you before the month's downtime budget is spent.

Status pages

Public or private status pages per client, so clients can check a site for themselves instead of emailing you.

If an outage followed a bad plugin update, safe updates with automatic rollback stop the next one before visitors see it.

Uptime targets

What uptime percentage should you promise a client?

Uptime is the share of time a site was reachable. The difference between targets looks tiny as a percentage and is huge in minutes.

Bar chart of downtime allowed per 30-day month: 7 hours 12 minutes at 99 percent uptime, 3 hours 36 minutes at 99.5 percent, 43 minutes at 99.9 percent, 22 minutes at 99.95 percent and 4 minutes at 99.99 percent
Downtime allowed per month. Calculated on a 30-day month of 43,200 minutes.
Downtime allowed at each uptime percentage
UptimePer 30-day monthPer year
99%7 h 12 min3 days 15 h 36 min
99.5%3 h 36 min1 day 19 h 48 min
99.9%43 min 12 s8 h 45 min 36 s
99.95%21 min 36 s4 h 22 min 48 s
99.99%4 min 19 s52 min 34 s

99.9 percent is the usual promise in a WordPress care plan and a sensible default for business sites. Promise only what the hosting can deliver, then measure it: the more often a site is checked, the closer the measured downtime is to what visitors really saw. Our guide to WordPress client reporting covers how to show the number to clients.

At scale

Uptime monitoring for multiple WordPress sites

Monitoring one site is easy. Monitoring forty means you need the worst problems first and nothing else shouting. Uptime is one part of how WPCentrify helps you manage multiple WordPress sites from one place, and our guide to WordPress site monitoring covers the other checks worth running.

  • Portfolio-wide availability in the fleet dashboard, worst first
  • Every site checked from all 3 locations, with no per-site setup
  • One email for a host-wide outage instead of one per site
  • Choose who gets which alerts, site by site
  • Critical URLs and logged-in pages watched per site
  • SSL certificates and domain expiry across the whole portfolio
  • Public or private status pages per client
  • Louder alerts for the sites that take payments or hold customer data
Answers

Questions about WordPress uptime monitoring

What people ask before they turn it on.

WordPress uptime monitoring is a service outside your site that loads it on a schedule, checks that a visitor would get a working page, and alerts you when they would not. WPCentrify checks every connected WordPress site from 3 locations in Malaysia, Canada and the USA, and emails you when an outage is confirmed.

As often as every 60 seconds, depending on your plan, from 3 locations: Malaysia, Canada and the USA. As soon as a check fails, the site is checked every minute on every plan until the result is certain.

On sites checked every minute, the email usually arrives 2 to 3 minutes after the site goes down. On the slowest check interval it can take up to about 7 minutes. The short wait is deliberate: by default the site has to fail three checks in a row and locations on different providers have to agree, so you hear about real outages, not network blips.

A site is down when a visitor would not get it: the server does not answer within 20 seconds, it returns a server error such as 500, 502 or 504, Cloudflare shows error 520 to 526 or 530, WordPress shows a critical error or a database connection error, the hosting account is suspended or shows a bare server page, the SSL certificate is broken, the domain no longer exists, or a maintenance page is still showing after 12 minutes.

No. Cloudflare challenges and blocks, Wordfence, Sucuri, Imunify360, ModSecurity, rate limits and password protection that turn away only the checker are not counted as down, because your visitors still get in. A plain "Forbidden" or "Not found" page with nothing else on it is not counted either.

Not at first. The "Briefly unavailable for scheduled maintenance" page that WordPress shows while it updates is not an outage, and no alert is sent while an update or restore run from WPCentrify is in progress. If a maintenance page is still showing after 12 minutes, it counts as down.

Yes. "There has been a critical error on this website.", "Error establishing a database connection." and PHP fatal errors printed in place of the page all count as down, even when the server labels the error page as a normal 200 response, which many hosts do.

A website down email when the outage is confirmed, a few reminders while it stays down and a back up email when it works again, with at most 4 emails per outage. Sites marked as taking payments, holding customer data or under a service agreement get their reminders twice as often, with an urgent subject line.

By email, the one alert channel for now. You choose which people get each kind of alert for each site, and when several of your sites with the same host go down together you get one email listing them, once you have told WPCentrify who hosts each site.

No. A site that still loads is not down, however slow it is. Speed and Core Web Vitals are tracked separately by WPCentrify performance monitoring.

No. The checks are ordinary page requests made from outside the site, a few per check, which is less than one visitor browsing a few pages. Nothing runs inside WordPress to make them happen.

Yes. As well as the homepage, you can watch the pages that matter most, such as a checkout or booking page, and pages behind a login, such as an account area that anonymous visitors never see.

Yes. An expired, mismatched or self-signed SSL certificate counts as down, and you can switch on a warning before a certificate expires. Domain warnings come 30 days before the registration runs out and again in the final week, for most domain endings.

Most care plans promise 99.9 percent, which allows about 43 minutes of downtime in a 30-day month. Only promise what the hosting can deliver, and measure against it. WPCentrify tracks each site against the figure you set and warns you before the month is used up.

Yes. Uptime figures go into the monthly client report, and you can give each client a public or private status page.

For a single site, a general uptime service may be enough. For several WordPress sites, WPCentrify checks each one from 3 locations in Malaysia, Canada and the USA, reads the page the way a visitor would so WordPress errors count as down, ignores firewalls and maintenance pages that do not affect visitors, and keeps each site's uptime next to its updates, backups and security.

Yes. Several uptime services have free plans, and WPCentrify is free during early access. When you compare free plans, check how often they look at your site, whether they read the page or only the status code, and whether an outage is confirmed from more than one location before you are alerted.

Early access open

Put three locations on every site you manage

Connect a site in under two minutes and it is checked from Malaysia, Canada and the USA from then on. Free during early access.

Free during early access. Keep your data, export any time.