SSL Certificate Monitoring: Why Auto-Renew Isn't Enough

The false security of auto-renew

Let us start with the uncomfortable truth: auto-renew for SSL certificates fails more often than you think. Not most of the time — but often enough that relying on it exclusively is a gamble you probably should not be making.

The promise of auto-renew is simple. You set it up once, and your certificate renews automatically before it expires. Tools like Let's Encrypt and Certbot have made this almost effortless. And when it works, it is brilliant.

The problem is the "when it works" part. Because when auto-renew fails — and it will, eventually — the failure mode is one of the worst in web hosting. Your site does not just go down. It goes down with a big scary browser warning that tells your visitors the site is not safe. Most of them will never come back.

How SSL certificates actually work (in plain English)

Before we get into what goes wrong, let us quickly cover what SSL certificates do. When someone visits your site over HTTPS, their browser and your server perform a handshake. Your server presents its SSL certificate, which proves two things: that the server is who it claims to be, and that the connection is encrypted.

The certificate has an expiry date — typically 90 days for Let's Encrypt or up to 1 year for paid certificates. After that date, browsers refuse to trust it. They show a full-page warning. Users see "Your connection is not private." And your site is effectively offline, even though the server itself is running perfectly fine.

This is why SSL failures are so insidious. Your server health checks pass. Your HTTP monitoring might even pass (depending on how it is configured). Everything looks fine from the inside. But from the outside, every visitor sees a security warning.

Seven reasons auto-renew fails in production

These are not theoretical scenarios. Every one of these happens regularly in production environments.

1. DNS record changes break validation

Most auto-renew systems use domain validation — they verify you control the domain by checking a DNS record or serving a specific file. If your DNS records change (maybe you switched to a CDN, changed hosting, or updated your nameservers), the validation step fails silently. The old certificate expires, and the renewal never completes.

2. Web server configuration changes

Certbot and similar tools need to serve validation files from a specific path on your web server. If someone updates the nginx or Apache config — adds a redirect, changes the document root, or blocks certain paths — the validation request gets a 404 and the renewal fails. It works fine for months, then an unrelated config change breaks it.

3. Hosting provider automation has bugs

Managed hosting platforms often handle SSL renewal themselves. But their automation is software, and software has bugs. Platform updates, infrastructure changes, or edge cases in your specific configuration can cause the auto-renewal to fail. You trust the platform, and the platform lets you down — silently.

4. Rate limits on certificate authorities

Let's Encrypt has rate limits. If you are managing many certificates (common for agencies or SaaS platforms), you can hit these limits. When that happens, renewals queue up and some might not complete before expiry.

5. The credit card on file expired

For paid SSL certificates, auto-renew charges your card annually. When that card expires, the charge fails. Most certificate providers send an email, but if it goes to a shared inbox or a former employee's email, nobody sees it. The certificate expires a year later, and you find out from a customer screenshot.

6. Certificate is renewed but not deployed

This is the sneakiest failure. The renewal succeeds — the new certificate is generated and sitting on the server. But the web server is still using the old one because it was not reloaded. Depending on your setup, you might need to restart nginx, reload Apache, or update a CDN configuration. If that step is not automated or fails, you have a valid certificate that is not being used.

7. Intermediate certificate chain breaks

An SSL certificate is not just one file — it is a chain. Your certificate, plus one or more intermediate certificates, linking up to a trusted root certificate. If the intermediate certificate changes (which happens when certificate authorities update their infrastructure) and your server still has the old chain, some browsers will show warnings even though your certificate is technically valid.

Real-world SSL failures

These are not hypotheticals. Major companies have been caught by SSL failures.

In 2020, Microsoft Teams went down for hours because an authentication certificate expired. The auto-renewal process failed, and the outage affected millions of users globally. The root cause? A certificate that was supposed to be automatically managed.

In 2021, Spotify experienced an outage when an expired TLS certificate broke their backend services. The certificate was internal, used for service-to-service communication — not something most monitoring tools would catch.

In 2023, several UK government websites displayed security warnings after certificates expired. These were managed by enterprise-grade hosting providers with auto-renewal in place.

If it happens to Microsoft, Spotify, and government agencies with dedicated infrastructure teams, it can happen to you.

What SSL monitoring actually checks

SSL monitoring goes beyond just checking the expiry date. Here is what a proper SSL monitor should verify.

Certificate expiry date

The most obvious check. How many days until your certificate expires? You want alerts at 30, 14, 7, and 1 day before expiry — giving you multiple chances to fix the issue before it affects users.

Certificate chain validity

Is the full certificate chain (your cert, intermediate certs, root cert) valid and correctly configured? A broken chain can cause warnings on some browsers and devices even if your main certificate is fine.

Certificate issuer

Who issued your certificate? If it changes unexpectedly — say, from DigiCert to an unknown issuer — that could indicate a misconfiguration or, in rare cases, a security issue.

TLS version and cipher strength

Is your server using TLS 1.2 or 1.3? Or is it still allowing older, insecure protocols? Modern SSL monitoring checks the actual encryption being used, not just whether a certificate exists.

Certificate matches the domain

The certificate must match the exact domain being served. A certificate for example.com does not automatically cover www.example.com or api.example.com. Monitoring verifies this match every time it checks.

How to set up SSL monitoring properly

Step 1: List all your SSL-protected domains

Not just your main domain. Subdomains (api.yoursite.com, app.yoursite.com, staging.yoursite.com), CDN domains, and any third-party domains you manage. Each one needs its own SSL monitor.

Step 2: Set up monitoring with multiple alert thresholds

Configure alerts at 30 days, 14 days, 7 days, and 1 day before expiry. The 30-day alert is your comfortable warning. The 1-day alert is your emergency siren. Most issues should be resolved before the 14-day mark.

Step 3: Check your score now

Before waiting for alerts, check your current SSL status. A free health check will tell you if your certificates are configured correctly, when they expire, and whether your certificate chain is valid.

Step 4: Do not just monitor — alert the right people

Your SSL alert should go to whoever can actually fix the issue. If your hosting provider manages SSL, loop in their support team. If your DevOps engineer handles it, make sure they get the alert directly — not buried in a shared inbox.

Step 5: Test the renewal process

Every few months, manually trigger a certificate renewal (in staging, obviously) and verify the full chain: renewal, deployment, server reload. Treat it like a fire drill. The time to discover your renewal process is broken is not when the certificate is about to expire.

SSL monitoring for agencies

If you manage multiple client sites, SSL monitoring is even more critical. You are responsible for dozens or hundreds of certificates, each with its own renewal process and potential failure mode.

The smart approach is to monitor every client's SSL certificate from day one — not as an afterthought, but as part of your standard client onboarding. When a client's SSL certificate is about to expire, you want to be the one who fixes it proactively, not the one who explains why their site showed a security warning for 6 hours.

For more on agency-specific monitoring needs, see our agency monitoring guide.

The bottom line

Auto-renew is a great first line of defence. But it is not the last line. SSL monitoring is the safety net that catches the failures auto-renew misses — before they become scary browser warnings that drive your customers away.

It takes less than a minute to set up. The peace of mind lasts as long as your site is online.

Frequently asked questions