SSL certificate expiry is one of the most predictable outages in existence. The expiry date is stamped right in the certificate — visible to anyone who looks. And yet, teams get caught by it constantly.
In this post, we'll cover how SSL certificate monitoring works, what you should be watching for, and how to make sure you're never the engineer who takes down a site because a cert expired on a Friday afternoon.
Why SSL certificate expiry is so common
The obvious question: if expiry is so predictable, why does it keep happening?
A few reasons:
1. Manual tracking is error-prone. Most teams either rely on calendar reminders or hope their cloud provider handles auto-renewal. Calendar reminders get missed. Auto-renewal silently fails more often than you'd think.
2. Certificate management is distributed. You might have five domains, each with a cert issued by a different provider, renewed on a different schedule, managed by a different team member. Nobody has a single view.
3. 90-day certificates changed the math. Let's Encrypt's 90-day certificates — now the default for most free SSL tools — mean you're renewing 4× more often than before. More opportunities for something to go wrong.
4. Auto-renewal doesn't always work. Certbot cronjobs fail silently. AWS Certificate Manager requires a DNS validation record that might not be in place. Manual intervention gets forgotten. The result: a cert expires even though you thought it was handled.
What to monitor
When monitoring SSL, you need visibility into three things:
1. Days until expiry
The most important signal. You want to know well in advance — not 3 days before it expires, but 60 days. That gives you time to investigate, escalate, and fix without rushing.
A sensible alert schedule:
- 60 days: First warning. Low urgency — something to note.
- 30 days: Medium urgency. Put it in the next sprint.
- 14 days: High urgency. Should be actively worked on.
- 7 days: Critical. Drop everything.
2. Certificate chain validity
A cert can be within its validity window but still fail — if an intermediate certificate in the chain has expired, been revoked, or isn't trusted by the browsers you care about. Your monitoring tool should validate the full chain, not just the leaf certificate.
3. Unexpected cert changes
If a certificate changes without your knowledge — same domain, different issuer, different key — that's a red flag worth investigating. It could indicate a misconfigured CDN, a load balancer pointing to the wrong origin, or in worst cases, a man-in-the-middle situation.
How automated SSL monitoring works
A good SSL monitoring tool does the following:
- Connects to your domain over HTTPS on port 443.
- Retrieves the certificate presented by the server.
- Validates the chain against the trust store (the same one browsers use).
- Checks the expiry date and computes days-until-expiry.
- Compares the fingerprint against the last known-good cert to detect unexpected changes.
- Repeats on a schedule — typically every hour or every few hours.
When the expiry crosses one of your configured thresholds, you get an alert through your configured channels: email, Slack, PagerDuty, SMS, whatever your team relies on.
Setting this up with siteRabbit
When you add any HTTP monitor to siteRabbit, SSL monitoring comes with it automatically. You don't configure it separately — just add your URL, and siteRabbit will:
- Track the SSL expiry date for that domain
- Alert you at 60, 30, 14, and 7 days before expiry
- Validate the certificate chain on every check
- Alert you if the certificate changes unexpectedly between checks
You can see expiry dates for all your monitored domains in your dashboard at a glance, so nothing gets missed even if you manage dozens of sites.
What to do when you get a warning
If your monitoring sends you a 30-day SSL expiry warning, here's a quick triage checklist:
- Is auto-renewal configured? Check your Let's Encrypt / Certbot setup, ACM, or hosting provider dashboard. Look for auto-renewal logs.
- Is the renewal working? Certbot logs are at
/var/log/letsencrypt/letsencrypt.log. Look for errors. - Is the renewal accessible? For HTTP-01 validation, make sure
/.well-known/acme-challenge/is accessible from the internet. For DNS-01, make sure the validation record is propagating. - Is there a CDN in front? Sometimes the CDN caches the old certificate. Purge the CDN or update the certificate in the CDN's dashboard separately.
If you're within 7 days: don't wait for auto-renewal. Renew manually, push the cert, verify in monitoring.
The takeaway
SSL certificate expiry is 100% preventable. The only reason it still happens is a lack of automated monitoring with proper early warnings.
Add your domains to an SSL monitoring tool, configure alerts starting at 60 days out, and you'll never have to apologize to customers for a certificate error again.