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
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 checks SSL certificate expiry dates automatically as part of its uptime monitoring. When a certificate is approaching expiry, Miterl sends alerts to your configured channels -- Slack, Chatwork, LINE, or email.
# Create a monitor with SSL certificate checking enabled
curl -X POST https://api.miterl.com/v1/monitors \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"url": "https://client-site.com",
"interval": 300,
"ssl_check": true,
"ssl_expiry_alert_days": 30
}'
The ssl_expiry_alert_days setting lets you receive staged warnings -- for example, at 30 days, 14 days, and 7 days before expiry. This gives your team enough time to investigate and fix renewal issues before they become client-facing incidents.
Recommended Workflow for Agencies
Here is a practical SSL monitoring workflow for agencies managing multiple client sites:
- Register all client sites in Miterl with SSL monitoring enabled
- 30-day alert -- verify the auto-renewal configuration is intact and schedule any manual renewals
- 7-day alert -- confirm renewal has completed successfully; escalate if it has not
- Monthly reporting -- include certificate status in your client maintenance reports as proof of proactive management
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
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.
For more details on SSL monitoring configuration, see the documentation. Try Miterl's monitoring in action at the Playground. If you have questions before getting started, check the FAQ.