An expired certificate is the only outage with a date printed on it. The expiry is set the day the certificate is issued. Nothing about it is a surprise, and yet it keeps taking down services that have every resource to prevent it.
- In December 2018, an expired certificate in Ericsson's network equipment cut 4G and SMS service for 32 million customers across 11 countries, including all of O2's UK mobile customers.
- On 3 February 2020, Microsoft Teams went down for hours for users worldwide. Microsoft's own explanation: an authentication certificate had expired.
- LinkedIn let the certificate on its link shortener, lnkd.in, expire in 2017, and did it again in 2019. Every shortened link on the network threw a browser security warning until it was renewed.
These are the famous ones. The unfamous ones happen every day on smaller sites, on staging environments that turned out to matter, and on internal endpoints nobody remembered had a certificate at all.
This post is about why the calendar keeps winning, why it is about to get harder, and what "handled" actually looks like.
Why a known date still causes outages
The failure is never "we did not know certificates expire." It is one of four narrower things.
The renewal ran and the deploy did not. Automation issued a fresh certificate and put it in the right place, and the process serving traffic kept the old one in memory. Reloading was a manual step, or a step that failed silently. The certificate on disk is valid; the one being served is not.
One certificate nobody counted. Most teams know about the certificate on the main domain. The one on the link shortener, the API subdomain, the mail server, the internal broker, the old marketing microsite still linked from the footer: those are the ones that lapse. LinkedIn's outage was not linkedin.com, it was lnkd.in.
The automation broke months ago. An ACME client that stopped being able to answer its challenge (a DNS change, a moved server, a revoked API token) fails quietly and keeps failing quietly until the last valid certificate runs out. The last valid certificate was issued when the automation still worked, so there is a long, calm gap between "renewal is broken" and "site is down."
Ownership moved. The person who set the reminder left. The calendar entry was in their calendar. The renewal email went to their mailbox. The organization still had the knowledge; it just did not have it anywhere that would act.
Notice that none of these are fixed by "set a reminder." A reminder is a plan to remember. The fix is a check that reads the certificate actually being served, from outside, on a schedule, and complains well before the date.
It is about to get harder, on a published timeline
The CA/Browser Forum, the body that sets the rules browsers enforce, passed ballot SC-081v3 in April 2025 with no votes against. It shortens the maximum lifetime of every publicly trusted TLS certificate on a fixed schedule:
| From | Maximum certificate lifetime |
|---|---|
| Today (until 15 March 2026) | 398 days |
| 15 March 2026 | 200 days |
| 15 March 2027 | 100 days |
| 15 March 2029 | 47 days |
A certificate that used to be renewed once a year will be renewed roughly every six weeks. Every one of the four failure modes above gets more chances to fire. The "renewal ran, deploy did not" case goes from a once-a-year risk to an eight-times-a-year risk on every host. Manual renewal stops being a bad practice and becomes an impossible one.
The intended response is automation, and automation is the right answer. It is also exactly the thing that fails silently for months. Shorter lifetimes make an external expiry check more necessary, not less: it is the only thing watching whether the automation is still doing its job.
What "handled" looks like
Three layers. Most outages come from having only the first.
1. Automated issuance and deployment. ACME (Let's Encrypt or any CA that supports it), a client that runs on a timer, and a reload hook so the serving process picks up the new certificate. This is table stakes and it is where most teams stop.
2. An external check of what is actually served. A monitor that performs a real TLS handshake against every hostname that matters, reads the certificate the server presents, and alerts on days remaining. External is the important word. Checking the file on disk tells you what you deployed. Checking from outside tells you what your users get.
3. An inventory that is the monitor list. The way to make sure the link shortener is counted is to make "has a monitor" the definition of counted. Every hostname with a certificate gets a check. When someone adds a subdomain, adding the monitor is part of the same change. If the inventory lives in a spreadsheet, the spreadsheet is the thing that will be wrong.
How RealUptime alerts on expiry
Every HTTPS monitor on RealUptime reads the certificate the server presents on each probe and tracks its expiry. So does every TCP monitor with TLS turned on, which is how you cover mail, databases, and brokers that never see an HTTP request.
Alerts fire at 30, 14, 7 and 1 days before the certificate lapses, through the same channels as everything else: Slack, email, PagerDuty, webhooks. Thirty days is deliberately long. It is enough time to discover that automation broke, fix it, and let it run, without the fix being an emergency. Fourteen and seven are the escalation. One day is the last call.
The remaining days show on the monitor in the dashboard, so a glance at the monitor list answers "what is expiring this month" without opening anything.
Two honest limits:
- For TCP monitors with TLS, the up/down result depends on the handshake completing, not on the certificate chaining to a public CA or matching the hostname. Internal services present private certificates all the time and reporting them down would be a false alarm. Expiry is still read and still alerted on. If you need "publicly valid" checked, use an HTTPS monitor on that host.
- The check reads what the server presents to our probe. If your edge presents a different certificate to different clients (some CDN configurations do), the check sees the one served to a plain client from our region.
Check one right now
The free SSL certificate checker does a live handshake against any hostname and shows the issuer, the expiry date, and the days remaining. No signup. Try it on the domain you forgot about, not the one you remembered.
Then put a monitor on it. Certificate expiry alerts are included on every HTTPS and TLS monitor, free tier included. The date is already decided. Whether it is an outage is up to whether something is watching.