WatchIn 2020, a certificate expired on a core Microsoft Teams service and locked millions of people out mid-pandemic, mid-workday. It wasn't a sophisticated attack or a hardware failure — it was a date passing on a calendar that nobody was watching. If it can happen to Microsoft, with all its engineers, it can happen to you. The good news is that this is one of the most predictable outages in all of computing: every certificate tells you, in advance, exactly when it will fail.
Why certificates expire silently
TLS certificates have a fixed lifetime — often 90 days, and getting shorter every year. Renewal is usually automated, which is exactly why it lulls teams into not thinking about it. But automation fails quietly: a cron job stops after a server migration, an ACME challenge breaks because of a firewall or DNS change, or a certificate sitting on a load balancer or mail server simply isn't covered by the automation at all.
The cruel part is the timing. Nothing tells you anything is wrong right up until the moment the clock ticks past the expiry date — and then everything breaks at once. Browsers throw full-page security warnings, logins fail, APIs reject connections and checkout stops working. A problem you could have fixed calmly two weeks earlier becomes a five-alarm fire.
What to monitor
For every TLS endpoint, monitor two things. First, the days remaining until expiry — this is your early-warning clock. Second, that the certificate is currently valid for the hostname it's serving. Checking validity rather than just presence catches a whole second class of problems: a wrong certificate, an incomplete chain that some clients reject, or a certificate that's technically present but doesn't match the domain.
It's worth understanding the difference, because a certificate can be perfectly un-expired and still break your site if the chain is misconfigured. Good monitoring checks both: is it valid now, and how long until it isn't?
How to set it up
Add a certificate monitor for each host and port that serves TLS. The obvious one is 443 for the web, but the certificates that catch people out are the ones they forget: 465 and 993 for mail, plus any custom service or internal tool with its own TLS. Walk your infrastructure and list every place a certificate lives — that list is almost always longer than people expect.
Then choose a warning window. Fourteen days is a sensible default: long enough that you're alerted while there's still time to renew calmly, short enough that the warning means something. Avoid the temptation to set it to a couple of days — you want margin for the renewal itself to go wrong.
Catching every expiry with WatchControl
This is exactly what certificate monitoring is for, and it's some of the highest-value monitoring you can set up because the failure is so total and so avoidable. In WatchControl you add a CERT monitor for each endpoint, set how many days before expiry you want to be warned, and route the alert to email, webhook or SMS — to a person, not a dashboard nobody checks.
Warn early and in stages — 30, 14 and 7 days — so a missed renewal escalates rather than slips through. Monitor every endpoint, including internal and mail services, not just your main website. And pair certificate checks with HTTP and keyword checks so you cover both “the certificate is fine” and “the site actually works.” WatchControl does all of this from the EU on a free plan, so the next expiry is one you hear about with two weeks to spare.