How to Monitor SSL Certificate Expiration Before It Breaks

To monitor SSL certificate expiration, run an automated check that connects to your domain over HTTPS, reads the certificate's "valid to" date, and alerts you when it is within a set window, usually 30, 14, 7, and 1 days out. Do it from an external service on a daily schedule so a lapse is caught even if the renewal cron fails, and watch every hostname you serve, including subdomains and APIs, because each certificate expires on its own clock. A lapsed certificate takes a healthy site fully offline in browsers, so this is one of the cheapest, highest-value checks you can automate.

Why an expired certificate is worse than a normal outage

When a TLS certificate expires, every modern browser throws a full-page security warning and refuses to load the site until the user clicks through scary text most people never do. Your servers are up, your app is fine, and your traffic still drops to near zero. Worse, the failure is invisible to a basic uptime check that only looks at the raw response, because the underlying service is technically responding. It is a self-inflicted outage with a known expiry date, which makes it entirely preventable.

The gap is that a plain check often reports the site as fine, which is one reason it helps to understand what uptime monitoring covers before assuming a green dashboard means nothing can lapse. Auto-renewal helps but does not remove the risk. Let's Encrypt certificates last 90 days and renew via a cron job or an ACME client, and those jobs fail more often than teams expect: a rate limit, a changed DNS record, a firewall rule, a full disk, or a renewal hook that silently errored. The certificate keeps counting down while everyone assumes automation has it handled. External expiration monitoring is the backstop that catches the renewal that did not happen.

What to actually check

Expiration date is the headline, but a complete SSL monitoring check looks at more than one field.

That last row is the one automation misses. A renewal can succeed on disk while the web server keeps serving the old certificate because it was never reloaded. An external check reads the certificate the world actually sees, so it catches the gap between "renewed" and "deployed".

How many days of warning do you need?

Alert at 30 days, then again at 14, 7, and 1 day before expiry. Thirty days gives you room to fix a stuck renewal without pressure, the shorter windows escalate if the earlier warnings were missed, and the one-day alert is the last line of defense. For a certificate you renew manually, start the warnings even earlier, at 45 or 60 days, so a purchase or approval has time to clear. The goal is to be reminded while it is a calm task, never to discover it from a customer screenshot of a browser warning.

How to monitor SSL expiration step by step

1. List every hostname you serve over HTTPS. The apex domain, www, each subdomain, your API domain, your status page, and any vanity domains. Each can carry a separate certificate with its own expiry. A wildcard covers subdomains but still expires, so it needs watching too.

2. Add an external SSL check per hostname. Point a monitor at each host on port 443. It connects, reads the certificate, and records the "valid to" date and the chain. Because it runs from outside, it sees exactly what a browser sees.

3. Set the expiry thresholds. Configure alerts at 30, 14, 7, and 1 days. Choose a channel that reaches a human who can act, Slack for the team and SMS for the last-ditch warning.

4. Run it daily, on a schedule you do not own. The whole point is a backstop independent of your server. A daily external check means a failed renewal is caught within 24 hours, long before expiry.

5. Verify after every renewal. When a certificate renews, confirm the external check shows the new, later date. If it still shows the old date, the server did not pick up the new certificate and needs a reload.

Certificates are part of how you run the server

SSL renewals rarely fail in isolation. They fail because of the same environment drift that breaks deploys: a changed DNS record, a firewall rule, a hook that errored during a release. If your certificates are issued and renewed as part of how you provision and deploy your servers, an external expiry check is the independent confirmation that the automation actually worked, from the one vantage point automation cannot fake, the public internet.

Common mistakes to avoid

Three patterns cause most certificate outages. The first is monitoring only the apex domain and forgetting a subdomain or the API host, which then expires alone. That mistake scales badly if you look after client sites, which is why agencies monitoring many domains track certificates per hostname rather than per client. The second is trusting the renewal log instead of the served certificate, so a certificate that renewed but never reloaded still lapses. The third is alerting on the day of expiry, which leaves no time to act if a purchase, DNS change, or approval is needed. Watch every hostname, check the certificate the public sees, and warn weeks ahead.

Where SSL monitoring fits in a full setup

Certificate expiry is one layer. A complete external watch also confirms the site loads, the right content is on the page, DNS resolves, and your APIs respond. Pairing an SSL check with fast uptime monitoring and a DNS check means the three quiet, preventable failures, an expired certificate, a bad DNS change, and a white-screen deploy, all page you before customers notice. For a store, that combination protects the checkout directly, which is why ecommerce uptime monitoring treats SSL as a first-class check rather than an afterthought.

The tool at the top of this page will check your certificate now and start watching its expiry from six regions, so the next renewal that quietly fails becomes an alert weeks ahead instead of an outage.