SSL certificate expiry monitoring: when you should be warned

You set up Let's Encrypt on your clients' servers, confirmed the renewal cron job, and moved on. That covers the common case. The problem is the uncommon case: a DNS record changes, port 80 gets blocked during a server migration, a rate limit is hit after repeated failed attempts, or Certbot stays behind on an old machine after the site moves. The renewal job runs, fails, and the certificate counts down toward expiry while your attention is elsewhere.

SSL certificate expiry monitoring is not a replacement for auto-renewal. It is the safety net that tells you when auto-renewal quietly breaks, with enough time to fix it before any visitor sees a security warning.

Why a single warning is not enough

Most tools send one notification, typically at 30 days before expiry. For a long-lived certificate, 30 days feels like plenty of runway. You see the alert, assume auto-renewal will handle it, and move on. If auto-renewal was already broken, you just used your only warning.

A single alert assumes nothing will go wrong between the reminder and the expiry date. What you actually need is a series of alerts at decreasing intervals, so that a failed renewal does not go unnoticed until the next checkpoint arrives.

The schedule that catches silent failures

Warnings at 14, 7, 3 and 1 day before expiry cover the realistic failure cases. Here is why each checkpoint earns its place.

14 days. The first alert arrives with enough buffer that you have several business days to investigate without urgency. At this point, most auto-renewals have not yet triggered. Let's Encrypt renews when a certificate has fewer than 30 days remaining, so this alert does not mean something is wrong. It means you are paying attention.

7 days. By now, Let's Encrypt should have attempted renewal. If the certificate has not renewed since the 14-day alert, that is your signal that something went wrong, and you have a week to fix it calmly. Seven days is enough time for DNS changes to propagate, for support tickets to get answered, and for a manual renewal to be tested.

3 days. If you are here without having renewed, the situation is urgent but still recoverable. This alert exists to catch anything that slipped through between the 7-day check and the wire.

1 day. This is the last-chance alert. If the certificate expires tomorrow and no renewal is in place, you need to act immediately. The 1-day alert is uncomfortable by design.

Certificate lifetimes are shrinking

Until March 15, 2026, public TLS certificates could be issued with a maximum lifetime of 398 days. As of that date, the CA/Browser Forum's new rules cap certificates at 200 days. In 2027 the limit drops to 100 days, and by 2029 it reaches 47 days, the figure the forum landed on after Apple proposed the change and Google supported it.

Those shorter lifetimes make automation more necessary, not less. A certificate that expires in 47 days gives you a tighter window to catch a broken renewal. With the old 398-day timeline, a renewal that slipped by two weeks was an annoyance you could recover from. On a 47-day certificate, two weeks of missed renewals eats nearly a third of your runway. More frequent renewals also mean more opportunities for the process to fail, at exactly the moment when the margin for error is shrinking.

Why auto-renewal breaks without telling you

Auto-renewal for Let's Encrypt certificates involves several moving parts, and any of them can fail independently without sending you a notification.

Domain validation fails. Let's Encrypt proves domain control by placing a challenge file on the server or querying a DNS record. A blocked port 80, an incorrect webroot path, or a DNS change that has not fully propagated will cause validation to fail. Certbot logs the error locally and does nothing else.

Rate limits. Let's Encrypt allows 5 failed validation attempts per hostname per hour. Repeated failures from a misconfigured server can exhaust this limit, after which all renewal attempts are rejected for a period, again with no outbound alert.

The renewal job was not transferred. When a site moves to a new server, the Certbot cron job or systemd timer stays on the old one. The new server has no renewal scheduled at all. There is no error because nothing runs.

Permissions changed. A security update or hosting change can revoke the permissions Certbot needs to write challenge files or reload the web server. The failure is written to the Certbot log, not to you.

The reason these failures are dangerous is that they are invisible by default. You do not get an email saying "renewal failed." The only signal is the expiry date approaching. If nothing is watching that date, you learn about the failure from your client.

For what actually happens when a certificate does lapse, including the browser warnings visitors see and how to recover quickly, see what happens when an SSL certificate expires.

What good SSL certificate monitoring looks like

A few properties separate useful monitoring from a false sense of security.

It checks the actual live certificate as seen from outside the server, not an internal configuration file. A certificate that was renewed but not correctly deployed will still show the old expiry date to the world, and a good monitor catches that.

It covers every domain you manage automatically. The certificates most likely to expire unnoticed are the ones issued once and forgotten: a subdomain for a staging environment, a mail server, a wildcard installed manually years ago. Add every domain when you set monitoring up, because the ones you leave out are the ones that will catch you.

It sends alerts through the channels you already use, email or Slack being the most common. An alert that goes to an inbox you check once a week is not much better than no alert.

For freelancers and studios responsible for a portfolio of client sites, a single monitoring service covering all sites at once is easier to maintain than individual alert jobs on each server, and it works even for sites where you do not have direct server access. If you are already watching uptime and response time across your portfolio, SSL expiry built into the same tool removes one moving part. The broader setup is covered in how to monitor your clients' websites.

FAQ

How far in advance should I get SSL expiry warnings?

Warning at 14, 7, 3 and 1 day covers the realistic failure cases. The 14-day alert gives you time to investigate without urgency, the 7-day alert confirms whether auto-renewal actually ran, and the 3 and 1 day alerts catch anything that slipped through. A single 30-day reminder relies on auto-renewal working perfectly, which is the case you are not preparing for.

Will shorter certificate lifetimes change how I monitor SSL?

Yes, directly. As of March 2026, new public certificates are capped at 200 days, with further reductions to 100 days in 2027 and 47 days in 2029. Shorter lifetimes mean more frequent renewals and less margin for error when a renewal fails. Staggered monitoring alerts become more important as the window between renewal attempts and expiry shrinks.

Does auto-renewal mean I do not need SSL expiry monitoring?

Auto-renewal handles the common case but fails silently in several scenarios: a blocked port 80, an incorrect webroot path, a DNS change, rate limits from repeated failures, or a renewal job left behind on a migrated server. Without monitoring, the first sign that auto-renewal failed is the expiry itself. Monitoring gives you multiple checkpoints to catch a broken renewal while there is still time to fix it manually.

What should I do when an SSL expiry alert fires?

First, check whether the certificate has actually renewed since the last alert. You can verify the current expiry date by clicking the padlock in any browser, or by running openssl s_client -connect yourdomain.com:443 </dev/null 2>/dev/null | openssl x509 -noout -dates. If renewal happened after the previous alert, no action is needed. If it has not renewed, check the Certbot log for error messages and run sudo certbot renew --dry-run to surface the exact failure before attempting a live renewal.

Should I monitor SSL on small client sites with little traffic?

Yes, especially small ones. A busy site tends to surface certificate problems quickly because visitors complain. A small brochure site can run with an expired certificate for days before anyone notices, and the first person to notice is usually the client. That is the outcome monitoring is there to prevent.

Trrack.it monitors SSL certificate expiry across all your client sites and alerts you at 14, 7, 3 and 1 day before a certificate lapses, so you always have time to catch a broken renewal before it becomes an incident. Your first site is free, so you can get started in a couple of minutes.