How SSL certificate expiry causes unexpected downtime

The certificate did not expire during the incident. It expired at 02:14 on a Tuesday, three weeks before anyone noticed. The outage just happened to start on a Saturday, when a campaign drove traffic to a checkout subdomain that nobody had loaded in a browser for a month.

The certificate on api.payments.example.com had lapsed. The uptime monitor was pointed at the marketing homepage on the apex domain, which had its own, perfectly valid certificate. So the dashboard was green while every payment request died with a TLS error the moment a real customer reached the checkout step.

Why the monitor stayed green

Most uptime checks answer one question: did this URL return a response. Plenty of them follow redirects, ignore certificate errors, or only ever look at one hostname. A monitor watching example.com tells you nothing about the certificate on api.payments.example.com, and a check configured to skip TLS verification will cheerfully report an expired host as up.

The renewal that quietly stopped renewing

The certificate was supposed to renew itself. It had, automatically, for over a year. Then someone migrated the DNS provider and the ACME DNS-01 challenge could no longer write its validation record. The renewal ran on schedule, failed, logged the failure to a cron email address that forwarded to a mailbox no one had opened since the person who set it up left. The existing certificate kept working, so nothing looked wrong. It kept working right up until the day it did not.

This is the part that catches teams out: expiry is a cliff, not a slope. There is no degradation, no rising error rate, no warning curve to alert on. At 23:59 the certificate is valid and everything is normal. At 00:00 every client gets a full-page security interstitial. The failure arrives complete and instantaneous, usually outside working hours.

What the traffic actually does

Browsers hard-block and almost no one clicks through a security warning, so for a public site an expired certificate is functionally a total outage. API clients are worse: they throw a TLS exception and many of them retry immediately and aggressively, so an expired internal certificate often arrives looking like a traffic spike or a thundering-herd problem, sending engineers to investigate load when the cause is a date. Mobile apps that pin certificates fail hardest and recover slowest, because the fix has to ship through an app store.

The most predictable outage in infrastructure is the one with the expiry date printed inside it.

Why good teams keep getting caught

It is almost never incompetence. It is that the knowledge lives in a place no one is watching:

• The person who issued the certificate has moved teams, and ownership moved with them
• A wildcard covers *.example.com, so everyone assumes example.com and api.staging.example.com are covered too. They are not
• Auto-renewal is trusted but never tested, so a silent failure goes unnoticed for the full validity period
• Staging, internal tools and admin subdomains are forgotten until a customer-facing integration calls one of them
• The 30-day calendar reminder was cleared the year the certificate was replaced early, and never recreated

The reliable fix is unglamorous: read the live certificate on every hostname that serves traffic, on a schedule, and alert on the expiry date with enough lead time to renew calmly. Validate the full chain, not just the leaf, because an incomplete chain fails in curl and on older devices while looking fine in Chrome. And confirm that a renewal actually deployed the new certificate, rather than trusting that the job which ran last month ran again last night.