The browser is the first thing to know, and it tells the user in the strongest possible language. Chrome shows a full-page interstitial with the error code NET::ERR_CERT_DATE_INVALID. Safari, Firefox, and Edge do the same. The padlock is gone. The address bar often turns red, depending on the browser. Mobile Safari on iOS is the harshest. A single tap on the warning and the user is offered a one-tap path back to the previous page or to Google. Most take the path away from your site.
Conversion impact shows up in the first hour
For an e-commerce site the cart fails to load. Tokenized payment fields do not render. Most form-submit endpoints will return a TLS error at the application layer, meaning the user's cart is not even submitted, the analytics do not receive the abandonment event, and the support team has nothing to look at until they manually check a checkbox in the dashboard.
If your payment processor's SDK does a preflight over HTTPS, and the major ones like Stripe and Adyen do, every checkout attempts to phone home, fails the handshake, and either retries a few times before declaring a network error or fails silently. Real-world numbers from site reliability write-ups put revenue loss in the first hour at five to fifteen percent of weekly revenue for mid-sized retailers. Bigger sites lose more.
Search engines demote you on a delay
Google has confirmed that HTTPS is a ranking signal and that expired certificates cause "this site may be hacked" style warnings that reduce click-through. The crawler itself keeps crawling, but the index quality score drops during the outage, and recovery takes longer than the customer-facing recovery. Sites that have had an expired-cert event show measurable ranking drops for several weeks after the certificate comes back.
Browser-level safety warnings also feed back into Chrome's telemetry, which can affect the per-site "Not Secure" treatment even after the certificate is replaced. It is not a clean bounce-back.
API integrations break faster than the browser does
Cloudflare's 525 and 526 errors are exactly this. A reverse proxy that fronts your backend has its own certificate to manage, and the moment that one is expired, every API call routed through it returns a hard error rather than the friendly HTML an end user would see. Webhook receivers fail. Status pages stop loading. CDN edges return errors to your monitoring provider, which means your existing observability misses the problem because the same outage is what is hiding the metric.
The cheap fix
The boring truth is that this is one of the cheapest outages to prevent and one of the most expensive to fix after the fact. A working expiry monitor with alert windows at 30, 15, 7, and 1 day before expiry covers almost every missed renewal. The 30-day reminder gives you time to coordinate the renewal. The 15-day covers the case where the first one slipped through. The 7-day and 1-day reminders are emergency brakes. Anything firing after the expiry date should page someone directly, not just land in an email folder.
Watch what is actually being served
Set up the monitor so it uses what is actually being served on port 443 today, not what is in a Certificate Transparency log or what was last deployed. CT logs are great for discovery but trail reality by minutes to hours. For an expiry alert, you want to talk to the certificate your users see.
A multi-host check that you can run on demand is the right complement to the always-on monitor. Between the two, you will know a certificate is going to expire before any of your customers do.
The bottom line
A single line of missed renewal can take a site offline, drop search rankings for weeks, and quietly break every API integration that touches your edge. None of that is hard to prevent. The cost is one external monitoring tool configured with your hostname list and a sensible alert cadence. The penalty for not having one is the kind of outage that ends up in the post-incident review.