How to Set Up SSL Certificate Expiry Alerts Before They Break Your Site

Why certificate expiry still catches good teams off guard

The whole point of an expiry date is that it is known in advance, so the failure mode is never surprise — it's silence. A calendar reminder set a year ago is on someone who has since changed teams. Auto-renewal was configured but the ACME client's cron job died quietly months back. The cert renewed fine on the load balancer but a second cert on an internal API endpoint nobody remembers didn't.

Certificate lifetimes are also shrinking. Let's Encrypt issues 90-day certs, and the industry is moving toward even shorter validity, which means the margin for a missed renewal is thinner every year. A yearly reminder simply doesn't map to a 90-day cert. You need something that watches continuously and nags on a schedule.

What an SSL certificate expiry alert should actually do

A good alert isn't a single ping on the last day — by then you're already firefighting. It's a tiered set of warnings that escalate as the deadline approaches, so a routine renewal never becomes an incident.

• 30 days out: informational — plenty of time to renew calmly or confirm auto-renewal ran.
• 14 days out: reminder — if nothing has renewed yet, someone should be assigned.
• 7 days out: warning — treat it as a task with a due date, not a nice-to-have.
• 1–3 days out: escalate to a channel a human actually watches (Slack, SMS, PagerDuty), not just email.
• Check the whole chain, not just the leaf — an expired intermediate breaks trust even when your own cert is valid.

The DIY check: openssl and a cron job

You can read a live certificate's expiry date straight from the endpoint with openssl. This one line prints the notAfter date for a host:

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -enddate

Wrap that in a small script that parses the date, compares it to today, and exits non-zero when you're inside your threshold — then run it from cron and let a failing exit send the alert. It works, and for one or two domains it's genuinely enough. The trouble starts at scale: SNI hosts serving multiple certs, endpoints behind auth, non-443 services (SMTP on 587, IMAP, internal gRPC), and the ongoing cost of keeping the script, its schedule, and its alert routing alive on a box you have to remember exists.

The gotcha almost everyone hits: the chain, not the cert

"But our certificate isn't expired" is the sentence you'll hear during a chain-related outage. A browser trusts your site only if it can build a complete path from your leaf certificate up through one or more intermediate certificates to a trusted root. Any link in that chain can expire or be misconfigured independently of your own renewal.

This is exactly what happened in the well-known Let's Encrypt DST Root X3 expiry — leaf certs were valid, but an expired root in the served chain broke older clients. Your monitoring has to validate the served chain end to end, not just diff a date on the leaf. A quick way to eyeball your chain and its dates is the free SSL checker; for a deeper walkthrough of what breaks and why, see what to do when an SSL certificate expires.

From a one-off reminder to continuous monitoring

The reason expiry alerts belong in a monitoring system rather than a calendar is that certificates are a moving target and people are not reliable schedulers. A monitor checks every domain and endpoint you own on its own cadence, validates the full chain, and routes tiered warnings to the right channel automatically — so a renewal that quietly failed still surfaces with days to spare. It's a different job from uptime checks, which is worth understanding before you assume your uptime tool has you covered: see SSL monitoring vs uptime monitoring.

This is the core of what VigilDog monitoring does — it watches SSL/TLS expiry across every certificate in your portfolio, checks the chain, and alerts early, so an expired cert never becomes the thing that pages you at 2am.