An SSL certificate expiring sounds like a paperwork problem. A date passed, a renewal was missed, surely the site still works underneath.
It does not. The moment the certificate expires, browsers treat your site as untrustworthy, and modern browsers act on that judgment immediately and without mercy. Understanding the full failure chain is the best motivation for making sure you never see it live.
The first minutes: a wall, not a warning
When a visitor opens your site on an expired certificate, they do not see your site. They see a full-page interstitial: "Your connection is not private," with your domain name and an error code underneath.
There is often a way to click through, buried behind an Advanced link. Almost nobody uses it, and they are right not to, because the warning is indistinguishable from the warning for an actively malicious site. To your visitors, your business now looks dangerous.
If you have HSTS enabled, the click-through option does not exist at all. The browser hard-refuses. That is HSTS working exactly as designed, and it means the stronger your security posture, the more absolute the outage.
So the first and largest cost is simple: effectively all of your web traffic stops at a wall. Not degraded. Stopped.
The same hour: everything that talks to your site
The browser wall is the visible failure. The quieter failures start at the same moment, because browsers are not the only things that verify certificates.
- Forms and checkouts are behind the wall with everything else. Quote requests, bookings, and orders stop arriving, and the people who tried do not retry somewhere else on your site. They retry at a competitor.
- APIs and integrations that call your domain start failing TLS verification. Payment webhooks, booking widgets embedded on partner sites, inventory syncs, anything that fetches from you over HTTPS.
- Email links still get clicked, and each click lands on the warning page, spending the trust your newsletter built.
- Automated services that fetch from you, feed readers, uptime checks from third parties, partner crawlers, log errors and back off.
A certificate expiry is not one outage. It is a simultaneous outage of every channel that verifies trust before talking to you, which in 2026 is all of them.
The following days: the slower costs
If the expiry lasts hours rather than minutes, slower-moving costs join in.
Search crawlers encountering certificate failures will retry, but a sustained failure window can affect crawl behavior, and the visitor signals during the outage, people arriving and immediately leaving, are not signals you want attached to your domain.
The reputational cost is harder to measure and very real. A meaningful fraction of the people who hit a security warning on your site will simply remember that your site felt unsafe. They will not file a report or send you an email. They will just not come back.
Why this still happens in the age of auto-renewal
Free certificates with automatic renewal are standard now, which makes expiry sound like a solved problem. The failure has moved, not disappeared. It now lives in the gap between "renewal is configured" and "renewal actually succeeded." Common versions:
- the renewal automation broke months ago and nothing was watching it
- a DNS change or migration invalidated the domain validation the renewal depends on
- the certificate renewed but the new certificate was never deployed to the server or CDN
- the www and apex are covered, but a subdomain certificate was provisioned separately and forgotten
- the renewal was tied to a credit card or account that lapsed
Every one of these passes a casual glance, because the current certificate is still valid right up until the day it is not. The configuration says renewed. Only the live certificate says the truth.
The monitoring that makes this a non-event
The defense is almost embarrassingly simple, which is exactly why it gets skipped: check the live certificate on a schedule and alert on the days remaining.
The honest version of that check has three properties:
- it inspects the certificate the public actually receives, not the renewal config's opinion of itself
- it covers every hostname that matters, apex, www, and any subdomains serving real traffic
- it alerts early enough to fix a broken renewal calmly, with a couple of weeks of runway, not the night before
This is squarely what recurring monitoring is for, and it is worth being precise about the claim. A certificate check is a narrow check. It does not audit your TLS configuration, your cipher choices, or your broader security posture. What it does is guarantee that the single most binary failure in web operations, the one that takes everything offline at a known future date, never arrives unannounced. Site Clinic includes live certificate checks in its monitoring loop for exactly that reason: it is cheap to watch, catastrophic to miss, and trivially verifiable from the outside.
What to do today
Look up your certificate's expiry date right now. Click the padlock in your browser, or use any free SSL checker. Note the date and who issues it.
Then answer one more question honestly: if the automatic renewal silently failed next month, what would tell you before your visitors did?
If the answer is nothing, that is the gap. Close it with a recurring check, and certificate expiry becomes what it should be: a date that passes quietly, year after year, without anyone noticing.