How to Prevent SSL Certificate Expiry Disasters

SSL Certificate Expiry Is Not Just an "Oops" Moment

When an SSL certificate expires, browsers display a full-screen warning: "Your connection is not private." Most visitors leave immediately. They do not investigate. They do not come back. For your client, this means lost traffic, lost sales, and lost trust -- all because of a certificate that should have renewed automatically.

Let's Encrypt and automated renewal have made SSL management easier, but expiry incidents still happen constantly. Here is why.

Why Auto-Renewal Fails More Often Than You Think

Common causes of SSL expiry despite auto-renewal being "configured":

• Server migration without transferring cron jobs -- the renewal script stayed on the old server
• DNS changes breaking domain validation -- the ACME challenge can no longer verify domain ownership
• Outdated certbot version -- the renewal process silently errors out
• Manually-obtained certificates -- nobody set up auto-renewal in the first place
• Disk full, certbot log write fails -- certbot exits silently with no trace in logs

For agencies managing many client sites across different hosting environments, catching a single failed renewal among dozens of domains is nearly impossible without automated monitoring.

Check SSL Expiry Dates Manually

Knowing how to check manually is a useful baseline skill.

# Check SSL certificate expiry dates
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null \
  | openssl x509 -noout -dates

# Example output:
# notBefore=Jan 15 00:00:00 2026 GMT
# notAfter=Apr 15 23:59:59 2026 GMT

This works for one domain. It does not scale to 50. That is where automated monitoring comes in.

Automate SSL Monitoring With Miterl

Miterl monitors SSL certificate expiry through a dedicated ssl monitor type. When a certificate is approaching expiry, Miterl sends alerts to the alert contacts you have attached -- Slack, Chatwork, LINE, or email.

Create an SSL monitor via the API

SSL monitoring is a standalone ssl-type monitor, separate from HTTP uptime checks. Use ssl_expiry_alert_days to set how many days before expiry the alert fires.

# Create an SSL certificate monitor (type: ssl)
curl -X POST https://miterl.com/api/v1/monitors \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Client Site SSL",
    "type": "ssl",
    "url": "https://client-site.com",
    "interval_seconds": 300,
    "ssl_expiry_alert_days": 30
  }'

The ssl_expiry_alert_days setting controls how many days before expiry the alert fires. Set it to 30 to schedule renewal early; add a second SSL monitor with a 7-day threshold for a final confirmation check. Run your HTTP uptime check as a separate type: "http" monitor alongside it.

Recommended multi-threshold alert setup

Bulk-Check SSL Status Across All Client Sites

When you manage 20 or 30 client sites, checking each one individually is impractical. Pull all monitor statuses at once via the API to quickly identify any that need attention.

# List all monitors with name, status, and 30-day uptime
curl -s "https://miterl.com/api/v1/monitors?per_page=100" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  | jq -r '.data[] | "\(.name)\t\(.status)\t\(.uptime_30d)%"'

If an SSL-type monitor shows down, the certificate has either expired or there is a chain validation error — act immediately. A down status before ssl_expiry_alert_days is hit means the certificate itself is invalid, not just approaching expiry.

Recommended Workflow for Agencies

A practical SSL monitoring workflow for agencies managing multiple client sites:

1. Register all client sites in Miterl with SSL monitoring enabled
2. 30-day alert -- verify the auto-renewal configuration is intact and schedule any manual renewals
3. 7-day alert -- confirm renewal has completed successfully; escalate if it has not
4. Monthly reporting -- include certificate status in your client maintenance reports as proof of proactive management

Including SSL certificate expiry dates in your monthly client reports makes the "what are we doing for you each month?" question easy to answer with a concrete, visible deliverable. For how to build and automate those monthly reports, see "Automating SLA Reports for Maintenance Subscriptions."

Do Not Skip the Basics: Verify Auto-Renewal

Alongside monitoring, periodically verify that your auto-renewal setup is actually working.

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

# Check the systemd timer status
systemctl status certbot.timer

# Review recent renewal logs
sudo journalctl -u certbot.timer --since "30 days ago"

Even when auto-renewal is working perfectly, monitoring serves as your safety net. The assumption that "it should be renewing automatically" is exactly the kind of assumption that causes outages at 2 AM on a Saturday.

Use Heartbeat Monitoring to Verify certbot Actually Ran

You can take SSL safety one step further by using heartbeat monitoring to confirm that certbot's renewal process executed — not just that it was scheduled to run. Add a Miterl heartbeat ping to certbot's --post-hook:

# Add to /etc/cron.d/certbot or as a systemd timer hook
# The heartbeat fires only when renewal succeeds
0 0,12 * * * root certbot renew --quiet \
  --post-hook "curl -s https://miterl.com/api/v1/monitors/YOUR_HEARTBEAT_MONITOR_ID/heartbeat \
    -H 'Authorization: Bearer YOUR_API_KEY' > /dev/null"

If certbot runs but fails silently, the heartbeat never fires and Miterl alerts you. This closes the gap between "the timer ran" and "the renewal actually succeeded." For more on heartbeat monitoring patterns, see "Heartbeat Monitoring: How to Verify Cron Jobs Are Running."

Pre-Launch SSL Checklist

For new site launches, SSL configuration is one of the most important items to verify before the domain goes live. The "Pre-Launch Monitoring Checklist" includes SSL verification steps alongside HTTP, DNS, and heartbeat setup in a single launch-day workflow.

Summary

SSL certificate expiry is not prevented by auto-renewal alone. Multiple failure modes exist, and the only reliable defense is layered: keep auto-renewal healthy and monitor independently.

• Expiry causes include missed cron migration, DNS validation failure, outdated certbot, and manually-issued certs with no auto-renewal
• Set up SSL monitors in Miterl across all client sites with 30-day and 7-day thresholds
• Run certbot renew --dry-run monthly to verify auto-renewal health
• Use heartbeat monitoring on the certbot post-hook to confirm successful execution, not just scheduled execution
• Include certificate status in monthly client reports to demonstrate proactive maintenance value

For more details on SSL monitoring configuration, see the documentation. Try Miterl's monitoring in action by signing up for free. If you have questions before getting started, check the FAQ.