SSL expiry alerts: never let your certificate lapse again

Certificates have a habit of expiring at three in the morning on a Sunday. By the time someone opens the site, every visitor is meeting a full-page red warning that says the connection is not private, and a fair number of them conclude the business has been hacked. Proper SSL expiry alerts are the cheapest insurance in web operations: a few minutes of setup against a very public failure.

The aim is not one reminder. It is a schedule of warnings, covering every certificate you own, delivered to people who are actually able to renew.

Why automatic renewal is not the end of the story

Plenty of sites renew automatically and still go down. Automation fails quietly in a handful of predictable ways.

• The renewal job stops running after a server migration, an operating system upgrade or a cron table that was not carried across.
• The validation challenge fails because a redirect rule, a firewall or a new CDN configuration blocks the path the certificate authority needs to reach.
• DNS-based validation breaks after the DNS provider or API credentials change.
• The certificate renews on disk but the web server is never reloaded, so it keeps serving the old one.
• A paid certificate renews on the vendor's side but nobody installs the new file, because the renewal email went to an inbox nobody reads.

Note the pattern: in most cases the renewal fails silently and the site keeps working until the exact moment it does not. Monitoring the actual certificate served to visitors, rather than trusting the automation, is the only reliable check.

A warning schedule at 30, 14 and 7 days

One alert is easy to miss. A staged schedule gives each warning a different meaning, so nobody has to remember the policy.

Thirty days out: plan it

This is the informational warning. It tells you a renewal is due, and it gives enough time to raise a purchase order, get an approval, or schedule a maintenance window if installation needs one. For a Let's Encrypt certificate on a 90-day cycle, 30 days remaining means automation has already had chances to renew and has not, which is a signal in itself.

Fourteen days out: act on it

Treat this as a task with an owner and a date, not a notification. If the certificate is still not renewed at fourteen days, someone should be checking why the automation did not fire rather than waiting for it to sort itself out.

Seven days out: escalate

At a week, the alert should go to a second person as well, and ideally to a channel the team watches during the day. Add a final alert at one or two days that is deliberately noisy, because at that point the only acceptable outcome is a renewed certificate.

Keep the alert text useful. It should name the hostname, the expiry date and time, the issuer and where the certificate is installed. An alert that says only "certificate expiring soon" sends someone hunting for basic facts.

Every host you serve, not just the main domain

Most lapses happen on hosts nobody thought to monitor. Build a list of every name that terminates TLS and check it against your monitoring:

1. The apex domain and the www version, which may not be on the same certificate
2. Subdomains such as shop, blog, admin, panel and app
3. API endpoints, including any used by a mobile app, which fail silently for users with no browser warning to see
4. Payment and webhook callback hosts, where an expired certificate breaks integrations rather than pages
5. Mail server hostnames used for IMAP, SMTP submission and webmail
6. Staging and demo sites, which embarrass you in front of exactly the clients you invited to look
7. CDN or proxy edge certificates, which are separate from your origin certificate
8. Any custom domain a customer has pointed at your platform

Wildcard certificates cover many subdomain names at once, but they still expire, and they do not cover a different apex domain or a second-level subdomain in every configuration. Monitor the certificate, not the assumption.

Who receives the alert matters as much as the alert

The most common failure is an alert that arrives correctly and lands in a mailbox belonging to someone who left the company.

Send to a shared mailbox or distribution list rather than an individual address, so the alert survives staff changes. Add at least one second channel, such as a team messaging group, because email gets filtered and phones get silenced.

Name a primary owner and a backup, and make sure both have the access they need: hosting panel, DNS, and the certificate vendor account. An alert delivered to someone who cannot log in just creates a forwarding chain.

Also check the contact address on the certificate vendor and registrar accounts themselves, and on the domain's technical contact. Those addresses are set once and forgotten for years.

Practical ways to set it up

You do not need an enterprise tool. Pick whichever of these fits your setup and confirm it works.

Most uptime monitoring services include a certificate expiry check with configurable thresholds. If you already run uptime monitoring, switching this on is usually one setting per monitor.

Hosting control panels and managed hosts often send their own certificate notices. Useful, but treat them as a supplement, since they only cover certificates that panel manages.

On your own server, a small scheduled script can read the expiry date from the live connection with the openssl client and send a message when the remaining days drop below each threshold. Run it from a machine other than the web server, so a server that is down cannot also silence its own alerts.

Finally, keep a plain calendar reminder as a backstop for any certificate that is installed manually. It is crude and it works.

Test the alert before you trust it

An untested alert is a belief, not a control. Verify it deliberately: lower a threshold temporarily so an alert fires today, confirm it arrives on every channel, and confirm both the primary and the backup recipient saw it. Then restore the threshold.

Repeat that test after any change to your monitoring, mail provider or team. Twice a year is enough for most small businesses, and it takes ten minutes.

Put your certificate list together this week

Open a blank document and list every hostname your business serves over https, with its expiry date, issuer and owner. Most owners find two or three names they had forgotten. Add each one to monitoring, set the three thresholds, and test that the alert arrives.

If you would rather not own the process, this is routine maintenance work. Our team covers certificate renewal and monitoring on the servers we manage under Linux hosting plans, and existing sites can be picked up through our support desk.

Frequently asked questions

How long are SSL certificates valid these days?

Free certificates from Let's Encrypt are issued for 90 days and are meant to be renewed automatically. Commercial certificates have historically been issued for about a year, and the maximum permitted lifetime has been shrinking over time, so check the actual dates on yours rather than assuming.

What happens the moment a certificate expires?

Browsers show a full-page warning that most visitors will not click past, so treat it as a complete outage. Mobile apps and server-to-server integrations usually fail outright with a connection error instead of showing anything to the user.

Can I renew a certificate early?

Yes. Renewing before the last day is normal practice and does not usually waste the remaining validity, because reputable issuers carry the balance forward. Renewing early is far safer than cutting it fine.

Do I need alerts if my certificate renews automatically?

Yes, and arguably more so. Automation removes the routine work but not the failure modes, and its failures are silent. The alert is what tells you the automation stopped working while there is still time to fix it.