WordPress Uptime Monitoring: How to Know Your Site Is Down Before Your Customers Do

The worst way to find out your WordPress site is down is from a customer. By the time they tell you — usually via an angry email or social media post — the site has been down for hours. Revenue is lost. Your credibility has taken a hit. And you're now triaging under pressure.

Uptime monitoring solves this by alerting you the moment your site goes down, not hours later. Here's how to set it up correctly.

What Uptime Monitoring Actually Is

An uptime monitor makes HTTP requests to your website on a schedule — every 1, 5, or 30 minutes — and verifies it gets a successful response. If the request fails (connection timeout, non-200 status code, or the response doesn't contain expected content), the monitor fires an alert.

The core metrics:
- Availability: Percentage of checks that returned a successful response
- Response time: How long each check took
- Incident duration: How long the site was unreachable
- Downtime history: Historical record of outages

An alert arriving within 1-5 minutes of a site going down is the difference between a 5-minute outage and a 3-hour one.

Types of Checks

HTTP Status Check

The most basic check: make a request to your URL, verify the HTTP status code is 200 (or 301/302 for redirects, which the monitor should follow).

What this detects:
- Server completely down
- Web server crashed
- DNS failure
- SSL certificate expired

What this misses:
- Database is down but WordPress shows a generic "error establishing database connection" page (which returns 200)
- A plugin conflict showing a PHP fatal error (which may return 200 with broken HTML)
- Performance degradation — the site is up but taking 15 seconds to load

Keyword Check

A keyword check verifies that the response body contains a specific string. This catches cases where the page loads but shows an error:

Monitor URL: https://yoursite.com
Expected keyword: </html> (or a unique string from your homepage, like your business name)

If WordPress's database is down, the page might return 200 with "Error establishing a database connection." A keyword check for your business name would fail, alerting you even though the HTTP status says 200.

For WooCommerce stores, monitor key pages separately:
- Homepage: check for your site name
- Product page: check for "Add to cart"
- Checkout page: check for "Place order"

SSL Certificate Monitoring

SSL certificates that expire cause browser security warnings that immediately destroy visitor trust. Monitors that track SSL expiry and alert 30 days before expiration give you enough time to renew without a crisis.

On well-managed hosting platforms, SSL renewal is automated and this alert should never fire. But certificate automation has failure modes — a domain transfer, DNS propagation issue, or CAA record misconfiguration can cause automated renewal to fail silently. An expiry monitor is your safety net.

Response Time Monitoring

Track how long your health check takes over time. A gradual increase in response time (from 200ms to 800ms over two weeks) indicates a growing problem — database queries getting slower, a background process consuming resources, a growing autoloaded options table — before it becomes an outage.

Set an alert threshold: if response time exceeds 3 seconds on three consecutive checks, send an alert. This catches performance degradation before it hits visitors.

Setting Up Monitoring

Free Tier Options

UptimeRobot (free for up to 50 monitors, 5-minute check interval):
1. Create account at uptimerobot.com
2. Add monitor: HTTP(S) monitor
3. URL: https://yoursite.com
4. Monitoring interval: 5 minutes
5. Alert contacts: your email and/or phone number via SMS

Free tier limitations: 5-minute intervals only, no keyword checks, basic alerting. Adequate for personal sites and small businesses.

Freshping (free for 50 monitors, 1-minute interval):
More generous free tier than UptimeRobot. Includes keyword checks on the free plan.

Better Stack (formerly Logtail, free for 10 monitors):
Includes on-call scheduling and incident management on free tier.

Paid Options Worth Considering

Pingdom ($15/month): 1-minute checks, real user monitoring, transaction monitoring for checkout flows.

Better Stack Pro ($20/month): On-call rotations, phone call alerts, status page.

Datadog Synthetic Monitoring ($5/monitor/month): Best-in-class transaction monitoring, integrates with Datadog observability stack.

What to Monitor

At minimum:
- Your homepage
- Your most critical business page (product page, pricing page, contact page)

For WooCommerce:
- Product page (random product)
- Cart page
- Checkout page

For blogs and content sites:
- Homepage
- One or two key article URLs

For SaaS applications:
- Marketing homepage
- Application login page
- Health check endpoint (/health)

Alerting Configuration

Alert Channels

Email: Reliable but easy to miss during off-hours. Good for non-urgent notifications.

SMS: High-attention alerts for critical outages. Most monitoring services charge per SMS on paid plans.

Phone call: For critical services, some monitors can call you. More intrusive but harder to miss at 3am.

Slack/Discord webhook: Route alerts to a team channel where multiple people see them. Ideal for team environments.

PagerDuty/OpsGenie: Enterprise-grade on-call management with escalation policies. Overkill for most small sites, essential for businesses with SLA commitments.

Alert Thresholds

Avoid over-alerting — a monitor that pages you for every 30-second blip trains you to ignore it. Configure:

Confirmation checks: Don't alert on the first failed check. Wait for 2-3 consecutive failures before alerting. Most transient errors (network hiccup, brief server restart) resolve within one check interval.

UptimeRobot: "Alert after N consecutive failures" — set to 2.

Alert timing: Different alert channels for different times:
- Business hours: Email and Slack
- Off-hours (nights, weekends): SMS or phone call

Recovery Alerts

When your site comes back up, get a recovery notification. This closes the loop on the incident — you know when it started and when it resolved, enabling you to calculate total downtime.

Building a WordPress Health Check Endpoint

A purpose-built health check URL is more reliable than monitoring the homepage. The homepage goes through WordPress template rendering, Cloudflare caching, and multiple plugin hooks. A health endpoint gives you a direct signal:

// wp-content/mu-plugins/health-check.php
// Place in mu-plugins to ensure it loads regardless of active plugins

add_action('init', function() {
    if ($_SERVER['REQUEST_URI'] !== '/health') return;

    $checks = [];
    $healthy = true;

    // Database check
    global $wpdb;
    $db_result = $wpdb->get_var("SELECT 1");
    if ($db_result == 1) {
        $checks['database'] = 'ok';
    } else {
        $checks['database'] = 'error';
        $healthy = false;
    }

    // WordPress options loaded
    $checks['wordpress'] = get_option('siteurl') ? 'ok' : 'error';
    if ($checks['wordpress'] === 'error') $healthy = false;

    // Write access to uploads
    $upload_dir = wp_upload_dir();
    $checks['uploads'] = is_writable($upload_dir['basedir']) ? 'ok' : 'warning';

    http_response_code($healthy ? 200 : 503);
    header('Content-Type: application/json');
    echo json_encode([
        'status' => $healthy ? 'healthy' : 'degraded',
        'checks' => $checks,
        'timestamp' => current_time('c'),
    ]);
    exit;
});

Monitor https://yoursite.com/health with a keyword check for "status":"healthy". This endpoint:
- Bypasses page caching (runs on init, before template loading)
- Checks database connectivity directly
- Returns 503 when degraded (triggers status-code-based monitors)
- Loads fast — no template rendering, no plugin output

Interpreting Uptime Data

The 99.9% Uptime Myth

"99.9% uptime" sounds impressive until you calculate what it means: 43.8 minutes of downtime per month. For a business that earns $100/hour from its website, that's $73/month in potential lost revenue — more than most hosting plans cost.

99.9% uptime is a minimum bar, not a goal. Well-run containerized hosting regularly achieves 99.95% or better.

Distinguishing Hosting Problems from WordPress Problems

When your monitoring alerts:

Connection refused or timeout: Web server or container is down. This is a hosting infrastructure problem.

503 Service Unavailable: Application crashed or is overloaded. Could be PHP crash (hosting resource limit), could be WordPress plugin causing a fatal error.

200 but wrong content: WordPress is up but showing an error. Run WP-CLI to check for PHP errors:

wp --info
wp plugin list
wp site check-update

Slow response time spike: Usually database — check slow query log. Can also be a runaway cron job or background process.

SSL certificate error: Check expiry date:

echo | openssl s_client -connect yoursite.com:443 2>/dev/null | openssl x509 -noout -dates

Status Pages

For businesses with multiple stakeholders (clients, team members, SLA commitments), a public status page shows current service health:

Better Stack Status Page (free): Connects to your monitors and shows public-facing status. Configure automatically based on your existing monitor checks.

Statuspage.io (Atlassian): Enterprise option with incident management, subscriber notifications, and embedded status widgets.

A public status page does two things: it demonstrates operational transparency to stakeholders, and it reduces support ticket volume during outages because visitors can check status themselves instead of emailing you.

The Monitoring Minimum

The absolute minimum monitoring setup for any site with business value:

1. UptimeRobot free account — add your homepage, set 5-minute checks, email alerts
2. Keyword check — verify the page contains something specific to your site content
3. SSL expiry monitor — alert 30 days before expiration
4. Recovery alerts — so you know when the incident is over

This takes 15 minutes to set up and provides the most important protection: knowing about outages before your customers do. Everything else — transaction monitoring, response time trending, status pages, on-call rotations — is built on top of this baseline.

The question isn't whether you can afford uptime monitoring. It's whether you can afford to find out about outages from your customers.