How to get alerted before an SSL certificate expires
Check every certificate you serve from outside, get reminders weeks ahead, and be paged when one is days from expiring or stops verifying.
Catch silent failures · 4 min read · Updated Oct 12, 2026
Certificates renew themselves, until one does not. A DNS record changes and the renewal challenge starts failing. The certificate lives on a load balancer nobody has logged into for a year. A wildcard was bought by hand by someone who has left. Renewal fails quietly for weeks, and then on one day every visitor gets a full-page browser warning.
The fix is not to trust the renewal. Check the certificate that is actually being served, from outside, every day.
How it works
A certificate check connects to a host the way a browser does, reads the certificate it is given, and looks at the expiry date. It does not care how the certificate is renewed or by whom. If renewal works, the date keeps moving forward and nothing happens. If renewal breaks, the date gets closer and you are told while there is still time to fix it.
A good check looks at more than the date. A certificate can be in date and still be rejected by browsers:
- The chain is incomplete. An intermediate certificate is missing, so some devices cannot verify it.
- The name does not match. The certificate was issued for a different host.
Step 1: List every certificate you serve
The certificate that expires is the one on the host everybody forgot. Work from a list, and think beyond the main site: www, api, app, the status page, mail servers, anything on its own load balancer.
Hosts that share a wildcard certificate still count one by one if they are served from different machines, because each machine has to be given the new certificate.
To read an expiry date by hand:
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -enddate
Ports other than 443 have certificates too. For mail, try 993 or 465.
Step 2: Decide when to hear about it
One alert on the last day is too late, and a daily alert for a month gets ignored. Use two kinds of signal at different volumes.
- Reminders at 30, 14 and 3 days, sent somewhere people read during working hours.
- A warning once the certificate is inside two weeks. If it renews automatically 30 days ahead, reaching 14 days means renewal has already been failing for a fortnight.
- An alarm in the last few days, treated like an outage, because it is about to be one.
If you renew by hand, move everything earlier, so there is time to buy and install a new certificate.
Who hears what. Send the reminders somewhere people read during the day, such as email or a team chat. Keep the phone for the alarm.
Step 3: Test it
You cannot make your own certificate expire to order, but there are public hosts that serve broken ones on purpose.
- Point a check at
expired.badssl.com. It should fail and say the certificate has expired. - Point one at
wrong.host.badssl.com. It should fail on the name. - Make sure the failure reached a person, then remove both.
That proves the alarm. The reminders cannot be triggered to order, so read their settings instead and confirm where they will go.
Common mistakes
- Monitoring only the main site. Work from the list.
- Checking the date on the server instead of from outside. The file on disk can be new while the web server still serves the old one, because it was not reloaded.
- Sending reminders to one person. People go on holiday. Send them to a shared channel.
- Turning off chain verification to stop an alert. The alert is right: some visitors' browsers are rejecting the site.
- Trusting the certificate provider's emails. They go to whoever ordered it, and say nothing about what your servers actually serve.
Doing this in saysOK
An SSL monitor takes a host and a port and checks it every hour. Its Expiry windows match the schedule above: by default the certificate is flagged at 14 days and the check fails at 3. It also verifies the full chain and that the host name matches, unless you turn those off.
A failing check alerts through any rule with the condition Monitor goes down. The 30, 14 and 3 day reminders come from a second rule, with the condition SSL cert near expiry; the SSL expiry warning template sets it up. Add from a domain tries the common host names on a domain, such as www, app and api, and proposes a certificate check for those it finds.
SSL checks are not in every plan; see pricing.
Next
A certificate is one of the things that takes a working site offline without any deploy. DNS is another: see how to monitor DNS records. So are scheduled jobs: see how to monitor a cron job.
Set this up in saysOK
Start on the free plan. The guide says where a step needs a paid one.