How to monitor WordPress site uptime and get downtime alerts

Monitor the public HTTPS URL that matters most, usually the home page. For a shop, also consider a lightweight product or checkout-related page, but do not monitor a page that requires a login unless your monitoring service supports authentication.

Use a URL that returns normal content without depending on a visitor session. A cached page can still return a successful response when the origin server is down, so decide whether you need to monitor the visitor-facing site, the origin, or both.

In WordPress, open Tools → Site Health and review the Status and Info screens. Site Health checks WordPress configuration, HTTP communication, loopback requests, scheduled tasks, PHP, the database, and other conditions that can explain an outage.

Do not treat this screen as your uptime alert system. It is an administrator-facing diagnostic, so an outside monitor is still needed to tell you when visitors cannot reach the site.

In your monitoring service, create an HTTP or HTTPS monitor for the chosen URL. Set the expected response to a normal success status, follow legitimate redirects, and use an interval that suits the site. If the service supports keyword checks, add a short phrase that should appear on the page so a generic error page is not counted as healthy.

For a single site, an external service is usually simpler than writing a WordPress plugin. WordPress cron runs when site requests trigger it, so a low-traffic or completely unavailable site cannot reliably run its own alert job.

Attach the alert contact to this specific monitor, enable both downtime and recovery notifications, and set a short delay or confirmation retry if the service provides one. Send alerts to an address or phone that is checked outside the affected website.

Trigger a controlled test, such as briefly pausing the monitor or using a staging URL, then confirm that the downtime and recovery messages arrive. A common mistake is creating an alert contact without attaching it to the monitor, or leaving the contact inactive or scoped to the wrong event.

Check from more than one region when possible, and allow the monitor to retry before declaring the site down. Review the incident timestamp, HTTP status, DNS, TLS certificate, redirects, server logs, and recent plugin or theme changes before contacting your host. Multiple checking locations can reduce alerts caused by one monitor region or network path.

Be careful with CDNs, WAF rules, bot protection, and maintenance windows. A CDN may serve cached content while the origin is unavailable, while a security challenge may block the monitoring agent even though normal visitors can load the site.

If you manage several WordPress sites through MainWP, MainWP Advanced Uptime Monitor is the quicker route. It is designed to centralise uptime checks and provide email or SMS downtime alerts from one dashboard, rather than requiring separate monitoring work for every installation.

Configure the sites, check interval, recipients, and alert rules, then run a recovery test before relying on it. Keep an external check or a second alert path for sites where a missed notification would have serious consequences.