The outage nobody schedules: how expired SSL certificates take sites down

Of all the ways a website can break, an expired SSL certificate is the strangest — because you’re told the exact date it will happen, sometimes months in advance, and it still takes teams by surprise. One morning the certificate lapses, and every visitor is met with a full-page browser warning: “Your connection is not private.” Most turn around immediately. Checkout stops. API clients that validate certificates start throwing errors. And the fix is trivial — renew the cert — but only once someone notices.

This is the outage nobody schedules but everybody could have prevented.

Why “it auto-renews” isn’t enough

The rise of Let’s Encrypt and automated certificate management made expiry feel like a solved problem. It mostly is — until it isn’t. Auto-renewal quietly fails more often than people expect:

• The renewal cron didn’t run — the server was down at renewal time, or the job was removed in a migration.
• The ACME challenge failed — a firewall change, DNS edit, or redirect broke the domain-validation step.
• The cert renewed but wasn’t deployed — the new file exists on disk, but the load balancer, CDN, or web server is still serving the old one because nothing reloaded it.
• A manually-issued cert (many internal services, some enterprise CAs) was never on auto-renewal at all.

In every one of these cases, your renewal tooling thinks it’s fine. The only way to know the truth is to check the certificate that’s actually being served to the public.

What good certificate monitoring checks

Monitoring the served certificate — not your renewal logs — closes the gap. A solid SSL check looks at:

• Days until expiry, with alerts well ahead of the deadline (30, 14, and 7 days is a sensible ladder), so a human has time to act.
• The full chain — an expired or missing intermediate certificate breaks trust even when your leaf cert is valid.
• Hostname match — the certificate actually covers the domain (and any www/subdomain variants) being requested.
• Validity window — that “not before”/“not after” dates are current, catching clock and issuance problems.

The key mental shift: verify what visitors receive, from the outside. Your renewal script’s success log is a promise; the served certificate is the fact.

A sensible alerting ladder

You don’t want one alert the day it expires — you want a runway:

• 30 days out: informational — put renewal on someone’s list.
• 14 days out: warning — if it hasn’t auto-renewed by now, investigate.
• 7 days out: urgent — treat as an active risk and fix today.

That spacing turns a potential emergency into a routine task, and it catches the case where auto-renewal silently stopped working weeks ago.

Don’t forget the quiet certificates

The public homepage cert usually gets attention. The ones that bite are the forgotten ones:

• API and webhook endpoints (api., hooks.)
• Admin panels and staging environments
• Mail servers and other non-HTTP TLS services
• Certificates on internal services that clients validate strictly

If a certificate secures something a machine or customer depends on, it deserves a monitor.

The bottom line

SSL expiry is the most preventable outage there is — the deadline is printed inside the certificate itself. The failure mode isn’t ignorance of the date; it’s assuming automation handled it. Monitor the certificate that’s actually being served, alert with enough runway to act calmly, and the “not private” screen becomes something you read about, not something your customers see.

Never get surprised by an expiry date again. Explore SSL certificate monitoring →