Why WordPress Sites Go Down

WordPress powers over 40% of the web, but that popularity comes with a unique set of reliability challenges. Unlike fully managed platforms, WordPress sites depend on a stack of interdependent components — PHP, MySQL, plugins, themes, and hosting infrastructure — and a failure in any one of them can bring the entire site offline. That is why external, plugin-free WordPress monitoring has become the reliable baseline: it watches your site from the outside, so it still alerts you when the site itself is down.

Here are the most common causes of WordPress downtime:

  • Plugin conflicts after updates — WordPress sites typically run 20–30 plugins. When one plugin updates and introduces a compatibility issue with another, the result can range from a broken page layout to a complete white screen of death (WSOD). This is the single most common cause of WordPress downtime.
  • PHP memory limits exceeded — Shared hosting plans often cap PHP memory at 128MB or 256MB. Resource-heavy plugins, large media libraries, or traffic spikes can push memory usage past this limit, resulting in fatal errors.
  • Database connection errors — The dreaded "Error establishing a database connection" message appears when WordPress can't reach its MySQL database. This can be caused by a crashed MySQL process, exceeded connection limits, or corrupted database tables.
  • Hosting resource limits — Shared hosting accounts share CPU, RAM, and I/O with hundreds of other sites. If a neighboring site spikes in traffic, your site's performance degrades — or your account gets temporarily suspended for exceeding resource limits.
  • Traffic spikes — A viral post, a Reddit mention, or a successful marketing campaign can overwhelm a WordPress site that isn't configured for sudden traffic surges. Without caching and a CDN, even modest viral traffic can crash a typical shared hosting setup.
  • Expired SSL certificates — If your SSL certificate expires, modern browsers block access entirely with a full-screen warning. Let's Encrypt certificates expire every 90 days, and auto-renewal doesn't always work as expected.
  • DNS misconfiguration — Changes to nameservers, A records, or CNAME entries during migrations or domain transfers can cause extended downtime if propagation takes longer than expected or if records are entered incorrectly.

What to Monitor on a WordPress Site

Monitoring just your homepage isn't enough. WordPress has several critical endpoints that can fail independently. Here are the five checks every WordPress site should have:

  • Homepage (HTTPS) — This is your basic uptime check. Monitor the homepage with keyword validation — verify that the page contains a specific string (like your site name) to catch cases where the server returns 200 OK but the page content is an error message or maintenance page.
  • /wp-admin/ — The admin panel runs through a different code path than the frontend. It's possible for the public site to work while wp-admin is broken (common with plugin conflicts). Monitoring this endpoint tells you if site administrators can log in and manage content.
  • /wp-json/ — The WordPress REST API endpoint is a reliable health indicator. If this returns a valid JSON response, it confirms that PHP is executing, the database is connected, and the core WordPress application is functional. A failure here often indicates a deeper infrastructure issue.
  • /wp-cron.php — WordPress uses wp-cron for scheduled tasks: publishing scheduled posts, checking for updates, sending email digests, and running plugin maintenance tasks. If wp-cron stops executing, these background tasks silently fail.
  • SSL certificate — Monitor your certificate expiry date with automated alerts at 30, 14, and 7 days before expiration. SSL monitoring catches renewal failures before they become user-facing outages.

Step-by-Step Setup with GoPinger

Here's a walkthrough to set up comprehensive monitoring for your WordPress site. The entire process takes about 5 minutes.

1. Create a Free Account

Sign up at app.gopinger.com/register. No credit card required. The free plan includes enough monitors to cover a single WordPress site's critical endpoints.

2. Add Your Homepage Monitor

Create a new HTTP(S) monitor with your site's homepage URL. Set the expected status code to 200 and add a keyword check — enter a unique string that appears on your homepage (your site title works well). This ensures you're alerted if the page loads but shows an error or maintenance message.

Set the check interval to 1 minute for production sites. For staging or development sites, 5 minutes is sufficient.

3. Add the REST API Endpoint

Create a second monitor for yoursite.com/wp-json/wp/v2. This endpoint should return a 200 status code with a JSON response. Use the API monitoring feature to validate the response — check that the content type header includes application/json.

This monitor catches database connection issues, PHP fatal errors, and plugin conflicts that might not surface on cached frontend pages.

4. Enable SSL Monitoring

When adding your homepage monitor, enable the SSL monitoring toggle. This automatically tracks your certificate's expiration date and sends alerts as the expiry approaches. Set warning thresholds at 30, 14, and 7 days.

5. Configure Alerts

Set up your preferred notification channels. At minimum, configure email alerts. For faster response times, add a Slack or webhook integration. If you're managing the site for a client, add their email as an additional alert contact so they're informed automatically.

6. Set Up a Status Page

Create a public status page and link your WordPress monitors to it. Share the URL with your clients or add it to your site's footer. When an incident occurs, the status page updates automatically — reducing "is the site down?" inquiries.

Advanced: Monitoring WooCommerce Endpoints

If your WordPress site runs WooCommerce, the stakes are higher — downtime directly blocks revenue. Add these additional monitors for comprehensive ecommerce coverage:

  • Shop page — Monitor /shop/ with keyword validation. Check for a product name or price that should always be present. This catches catalog display issues.
  • Checkout page — Monitor /checkout/ for availability. The checkout page is the highest-value page on your site. A broken checkout with a working storefront means customers can browse but never buy.
  • WooCommerce REST API — Monitor /wp-json/wc/v3/ to verify the commerce API layer is functional. This is especially important for headless WooCommerce setups or sites with mobile apps.
  • Response time alerts — Set response time thresholds on your checkout and product pages. Studies show that a 1-second delay in page load time reduces conversions by 7%. If your checkout page normally responds in 400ms and suddenly takes 3 seconds, you want to know — even if it's technically still "up."

Common WordPress Monitoring Issues and Fixes

"My site returns 200 but shows an error page"

WordPress sometimes returns a 200 OK status code even when displaying an error message or a plugin's debug output. The fix: always use keyword validation. Add a word or phrase that appears on your normal page but wouldn't appear on an error page. Your site name in the footer is a reliable choice.

"I keep getting false positives from maintenance mode"

When you update WordPress core or run plugin updates, the site briefly enters maintenance mode — returning a 503 status. If your monitoring triggers on every brief update, use maintenance windows in your monitoring tool to suppress alerts during scheduled update times. Alternatively, set your monitor to require 2–3 consecutive failures before alerting, which filters out these brief maintenance windows.

"wp-cron shows as down but my scheduled posts are publishing"

Many managed WordPress hosts disable the built-in wp-cron.php and replace it with a real server-side cron job. This is actually better for performance and reliability. If your host does this, wp-cron.php may return a 404 or be blocked — this is expected and normal. Check with your host before adding a wp-cron monitor to avoid unnecessary alerts.

"My monitoring shows the site is up but users say it's slow"

Basic uptime checks only verify that the server responds. They don't measure the full page load experience. Set response time thresholds on your monitors (e.g., alert if response time exceeds 2 seconds). Also consider that cached pages may respond fast to monitoring checks while logged-in users or uncached pages are slow — monitor both a cached and uncached endpoint for complete visibility.