SSL Certificate Monitoring for WordPress Agencies

The One Line a WordPress Maintenance Provider Should Never Say

"Sorry, the SSL certificate expired."

For agencies running WordPress maintenance services across multiple clients, an SSL expiry incident is one of the most preventable — and most embarrassing — failures possible. The assumption that Let's Encrypt auto-renewal "just works" is exactly what causes 2 AM emergencies.

This article covers how to centralize SSL certificate expiry management across all client sites, detect renewal failures before they cause outages, and fold SSL monitoring into your maintenance service offer. For the broader context of adding uptime monitoring to WordPress maintenance plans, see "Add Uptime Monitoring to WordPress Maintenance Plans." For a general guide on SSL monitoring, see "How to Prevent SSL Certificate Expiry Disasters."

WordPress-Specific SSL Auto-Renewal Failure Patterns

General auto-renewal failure causes apply to any environment, but WordPress hosting adds several failure modes that are less obvious.

Failure Modes Specific to WordPress

1. Shared hosting auto-renewal is not global — it is per-domain

On shared hosting platforms, Let's Encrypt auto-renewal often requires enabling it per domain through a control panel, not as a global setting. Adding a new domain without toggling auto-renewal for that specific entry means the first renewal attempt will fail silently.

2. Server migrations do not carry over certbot configuration

When migrating a WordPress site to a new server, the focus is on files, database, and DNS. The certbot setup on the old server does not transfer automatically. The certificate may still be valid at migration time, but the next renewal attempt fails because certbot was never configured on the new server.

3. Caching plugins interfere with ACME challenges

W3 Total Cache, WP Super Cache, and similar plugins can cache the .well-known/acme-challenge/ path that Let's Encrypt uses for domain validation. When the ACME challenge URL returns a cached response instead of the expected challenge file, domain validation fails and renewal is blocked. Cache exclusion rules can also disappear after plugin updates.

4. WordFence blocks certbot requests

WordFence and similar security plugins may classify the certbot agent's HTTP requests as bot traffic and block them with a 403. Renewal that worked fine before a WordFence configuration change may silently start failing afterward.

# Check ACME challenge access in Nginx logs
grep "acme-challenge" /var/log/nginx/access.log | tail -20

# Look for 403 or 404 responses — these indicate a caching plugin or firewall is blocking certbot
# The challenge URL should return 200

Centralizing SSL Monitoring Across Client Sites with Miterl

Create SSL Monitors for Each Client Site

Miterl monitors SSL certificate expiry through a dedicated ssl monitor type. When a certificate's remaining days drop below the configured threshold, an alert fires to the contacts you specify (Slack, Chatwork, LINE, etc.).

# Create an SSL monitor for a WordPress client site
curl -X POST https://miterl.com/api/v1/monitors \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Client A - SSL Certificate",
    "type": "ssl",
    "url": "https://client-a.com",
    "interval_seconds": 3600,
    "ssl_expiry_alert_days": 30,
    "alert_contact_ids": [1]
  }'

Setting ssl_expiry_alert_days to 30 triggers an alert when 30 days remain before expiry. The recommended setup for agencies is three thresholds: 30 days (schedule renewal), 14 days (confirm renewal is in progress), and 7 days (final escalation). Create a separate monitor for each threshold.

Bulk-Register Multiple Sites for SSL Monitoring

If you manage ten or more sites, a simple shell loop is faster than registering through the dashboard one at a time.

# Bulk-register multiple client sites for SSL monitoring
DOMAINS=(
  "client-a.com"
  "client-b.co.jp"
  "client-c.net"
)

for DOMAIN in "${DOMAINS[@]}"; do
  curl -X POST https://miterl.com/api/v1/monitors \
    -H "Authorization: Bearer YOUR_API_KEY" \
    -H "Content-Type: application/json" \
    -d "{
      \"name\": \"${DOMAIN} - SSL\",
      \"type\": \"ssl\",
      \"url\": \"https://${DOMAIN}\",
      \"interval_seconds\": 3600,
      \"ssl_expiry_alert_days\": 30
    }"
  echo "Registered: $DOMAIN"
  sleep 1
done

SSL Monitors and Uptime Monitors Are Separate — Set Up Both

SSL monitoring (type: ssl) and HTTP uptime monitoring (type: http) are independent monitor types. Set up both for each client domain.

If an SSL monitor reports down, the certificate has already expired or a certificate chain problem exists. This requires immediate action regardless of whether the alert threshold has been reached.

Using the Expiry Dashboard to Track All Certificate Dates

Miterl tracks the expires_at value for each SSL monitor and surfaces it in the expiry dashboard, giving you a single view of every client certificate and how many days remain.

# Retrieve expiry data for all SSL monitors via the API
curl -s "https://miterl.com/api/v1/monitors?per_page=100" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  | jq -r '.data[] | select(.type == "ssl") | "\(.name)\t\(.status)\t\(.expires_at)"'

Run this before preparing monthly maintenance reports to catch any certificates approaching expiry across all clients in a single command.

WordPress-Side Configuration to Prevent ACME Challenge Failures

Monitoring catches failures after they occur. These configuration steps reduce the frequency of renewal failures in the first place.

Exclude the ACME Challenge Path from Caching Plugins

In W3 Total Cache, WP Super Cache, WP Fastest Cache, or any similar plugin, add the following path to the cache exclusion list:

/.well-known/acme-challenge/

To set this at the web server level directly in WordPress .htaccess:

# Bypass cache for ACME challenge verification
<IfModule mod_rewrite.c>
  RewriteRule ^\.well-known/acme-challenge/ - [L]
</IfModule>

Verify certbot Auto-Renewal Periodically

# Test auto-renewal without actually renewing
sudo certbot renew --dry-run

# Check the systemd timer status
systemctl status certbot.timer

Running --dry-run monthly confirms that certbot can still complete the renewal process successfully. A clean dry-run result means the certificate will renew when the time comes.

Building SSL Monitoring into Your Maintenance Service Offer

SSL certificate monitoring is one of the easiest maintenance items to explain to clients — and one of the most persuasive for demonstrating proactive value.

Adding SSL Status to Monthly Reports

A single line in your monthly maintenance report turns invisible background work into visible client value:

SSL Certificate Status: Healthy (XX days remaining)
Next renewal scheduled: YYYY-MM

When nothing went wrong that month, this line proves why the maintenance contract exists.

Pricing SSL Monitoring as Part of WordPress Maintenance Plans

A rough guide for incorporating SSL monitoring into tiered maintenance pricing:

The value proposition is straightforward: the client is paying to not get a call from their customers about a broken padlock icon. For the broader framework of adding monitoring to WordPress maintenance pricing, see "Add Uptime Monitoring to WordPress Maintenance Plans."

SSL Monitoring Plus the WordPress Plugin

SSL monitoring handles the certificate side and the HTTPS surface from outside. There is still a class of false alarm that SSL and uptime monitors cannot avoid: during a WordPress core, plugin, or theme update, the HTTPS response momentarily fails and external monitors mark the site down. Suppressing the alert through the maintenance Webhook works perfectly when a human or a deploy script calls it — but on WordPress sites that auto-update themselves, no one is at the keyboard to make that call.

Miterl Connect is the official WordPress plugin for exactly this gap. When an update starts, it tells Miterl to open a one-hour maintenance window automatically and close it the moment the update finishes. External monitoring stays on; the false alarm stops at its source. Designed to run alongside SSL monitoring, not replace it. Setup steps and how to issue the connection key are in the documentation.

Frequently Asked Questions

How far in advance does Miterl alert on SSL expiry?

Based on the ssl_expiry_alert_days value you set (the recommended setup is three separate monitors at 30, 14, and 7 days). What matters more than the number is the detection method: Miterl performs an actual TLS handshake against your server and reads the live certificate's expiry date directly. It does not rely on Let's Encrypt renewal logs, so it catches failures regardless of the cause — a caching plugin blocking the ACME challenge, WordFence rejecting certbot, or a migration that never carried over the certbot config all show up the same way: the certificate simply isn't renewing.

Can I see SSL and domain expiry in the same dashboard?

Yes — Miterl's Expirations dashboard shows both SSL certificate expiry and domain registration expiry in one view. Neither is available on the Free plan, though: SSL certificate monitoring (type: ssl) requires Standard or above, and domain expiry monitoring (the whois monitor type) is Pro-only. If you're running SSL monitoring as part of a paid maintenance offer, Standard or higher is the plan to use.

What check interval should I use for SSL monitoring?

Certificate expiry dates typically only change every few months, so a 1-hour interval is more than sufficient. Each plan also has a minimum interval floor — 5 minutes on Free, 3 minutes on Standard, 1 minute on Pro — but there is little practical benefit to running SSL checks more frequently than that floor for this monitor type.

If an SSL monitor shows "down," does it need immediate attention?

Yes. A down status on an SSL monitor means the certificate has either already expired or there's a certificate chain or handshake problem. This requires immediate action even if you haven't yet reached the ssl_expiry_alert_days threshold you configured for advance warning.

Summary

Preventing SSL certificate expiry incidents across multiple WordPress client sites requires both a reliable renewal mechanism and independent monitoring that catches failures before clients notice.

• WordPress-specific failure modes include caching plugin interference with ACME challenges, security plugin blocks on certbot, and certbot configuration not surviving server migrations
• Create ssl type monitors in Miterl for each client site with 30-day, 14-day, and 7-day alert thresholds
• SSL monitors (type: ssl) and uptime monitors (type: http) are separate — configure both for every domain
• Use the expiry dashboard and the monitors API to pull all certificate dates into one view for monthly reporting
• Exclude .well-known/acme-challenge/ from caching plugins and run certbot renew --dry-run monthly to keep the renewal mechanism healthy

SSL monitoring is a low-effort, high-visibility maintenance item that clients understand immediately. Beyond certificate health, WordPress sites are also prone to gradual response time degradation caused by WP-Cron accumulation, plugin conflicts, and image processing overhead — issues that never trigger a downtime alert. "WordPress Speed Monitoring for Web Agencies" explains how to track these WordPress-specific speed patterns and include them in your monthly maintenance reporting alongside SSL certificate status. Sign up for free to try it across your client sites. For full configuration details, see the documentation. Agency-specific scenarios are also covered in the use cases section.