Certificate lifetimes have shrunk faster than most teams' playbooks. Five years ago a one-year cert was the standard. Today Let's Encrypt hands out 90-day certificates by default and the CA/B Forum caps public TLS certificates at 398 days, with a fresh round of changes reducing that to 200 days for certificates issued after March 15, 2026. The shorter lifetimes are a security win, but they punish anyone running manual renewals. A single forgotten certificate can drop production, kill search rankings, and push real customers away in a single afternoon. That is why SSL certificate expiry monitoring has shifted from a nice-to-have into an operational baseline.
What good monitoring actually needs to do
The goal isn't to watch a list. The goal is to get a reminder early enough that the right person can act without dropping everything else. Here is what actually works in 2026.
Pick a layered alert cadence
Pick four or five checkpoints spread out before the expiry date. The standard is 30, 15, 7, 1, and 0 days. The 30-day reminder is the workhorse. It gives you time to open a ticket, find the right service owner, and run a deploy. The 15-day alarm exists because the first one usually gets triaged into a backlog queue. The 7-day and 1-day reminders are emergency brakes. Anything firing past the 0-day mark is a SEV-1 with the on-call engineer paged, not an email to a shared inbox.
Each tier should hit a different channel, ideally with the loudest reminder going to whatever pager or chat channel your team actually opens within minutes, not hours.
Watch every hostname you serve (plus the ones you used to serve)
The mistakes that produce outages usually involve a certificate that has been forgotten because nobody replaced it after a CNAME move or a service migration. A good monitoring tool pulls live data from the certificate being served on port 443, not from Certificate Transparency logs or any cached snapshot, because what matters is what your users actually see over TLS today.
Wire renewal automation before you tune the dashboard
A clean tool that polls a list of hostnames is worthless if the response to every alert is "open a PR and schedule a deploy for next sprint." Teams that have the easiest time with 90-day certificates run end-to-end automation. ACME for Let's Encrypt, an API-driven CA for commercial certs, cert-manager in Kubernetes, or a properly tested pipeline script for traditional hosts. Once renewal is on rails, the alert cadence stops being "did we renew?" and starts being "did the renewal actually deploy?"
Add a public check tool as your long-tail safety net
Most production certificate outages aren't spotted by the team that owns the service. They are spotted by a customer, a partner, or a search-engine crawler visiting a different hostname that shares infrastructure. A standalone check tool that lets anyone paste a hostname and see its issuer, valid-to date, and days remaining is the cleanest early-warning system for the long tail of properties that nobody is actively watching. Set a recurring reminder to run it across every hostname you own, including staging and dev environments, on the same cadence the production monitor runs.
The pattern that holds up under pressure
It is the boring one. A real-time source of truth, a layered alert cadence, renewals on autopilot, and a public fallback check for the properties that slip through the cracks. None of that is exotic anymore. It is table stakes for running TLS in 2026.