On-demand SSL renewal watchlist
Paste a bunch of hosts, hit check, and watch them sort by days left. You pick the review threshold. The list saves right here in your browser, and you can copy a renewal report whenever. The whole point is catching a cert before it dies on you and takes visitors, an API, or your own admin login down with it.
This runs when you ask it to. It won’t ping you in the background, so don’t treat it as an alert service. The saved list just lives in this browser so the next rerun is one click.
Why an SSL expiry monitor belongs in the admin routine
A dead cert is a dumb way to take a site down, and it happens constantly. Visitors hit a scary browser warning. API clients just refuse to connect. Half your embedded widgets break. And the support tickets land way before anyone figures out the cause is something as boring as an expired certificate. Here’s the annoying part: it might have renewed fine last month and still fail this month. A DNS challenge broke. Somebody swapped a CDN hostname. A staging box got exposed. Or the person who owned renewals left and nobody’s watching that account anymore.
A watchlist drags that risk back into something boring and manageable. Rather than poking at one domain whenever it crosses your mind, you keep the public hostnames in one place, run them all at once, and let the list sort itself so the nearest cliff is right at the top. That’s useful for the main site and its www twin. It’s even more useful for the stuff that quietly matters: dashboards, APIs, anything handling payments or logins, the odd client microsite, whatever tool subdomain people actually depend on.
What this on-demand monitor checks
- Whatever certificate is actually being served on port 443 for each host, right now.
- The validity dates, and how many days you’ve got left.
- Issuer and subject common-name hints, when the cert bothers to hand them over.
- Whether the hostname you typed lines up with a SAN entry or the subject name in the parsed summary. It usually does. Sometimes it really doesn’t.
- A review date worked back from the threshold you picked.
- Anything that failed to connect or failed the cert check, which is the stuff you want to look at first.
How to choose a renewal threshold
Fourteen days is cutting it close. Honestly, that’s barely a warning at all if something in your pipeline is broken. Thirty is the floor I’d suggest for a plain little site. Sixty feels saner once DNS validation, CDN edges, or three people who all think someone else owns renewals enter the picture, and that’s where I usually land. Ninety is for teams who want the renewal work showing up on a board before a cert hits its last stretch. None of this is about panicking early. It’s just buying yourself enough runway to fix the challenge path and retest the live hostnames without sweating.
A practical renewal workflow
- Keep the list to hostnames real people or real integrations actually open. Don’t pad it.
- Run it before anything risky: a migration, a DNS change, a CDN swap, a release window.
- Look at the soonest cert first. Then the outright failures. Then the hostname mismatches that aren’t on fire but still smell wrong.
- Before the final week, confirm auto-renew is alive, you own the DNS challenge, and there’s a manual fallback if it all goes sideways.
- Once it’s renewed, rerun the exact public hostname. And if HTTPS started behaving differently, go poke at the headers or redirects.
Monitoring is more than one date
Expiry is the loud signal. The quieter stuff around it trips people up just as often. A cert with months left can still be flat-out wrong for a hostname you just added. A renewal can succeed on the origin while your CDN happily keeps serving the old one. And a wildcard covers one tier of subdomains while a deeper name sits outside it, completely uncovered. So keep both tools handy. Use this monitor for fast triage, and when one host looks off, open the certificate checker and actually read it.
Common questions
Will this send me an email when SSL expires?
Nope. It checks the watchlist live, but only when you click, and it’ll stash the host list in this browser. That’s it. Real alerting means scheduled checks running on their own plus something that actually delivers the notification, and that lives on a server, not a page you opened.
Should I monitor the apex and www names separately?
If both are public, yeah, watch them on their own. They can terminate at different edges or sit behind different redirects, so they really aren’t the same check. And a break on the name nobody talks about still wrecks the day for whoever happens to land on it.
What should I do when a host fails the SSL check?
Start with the basics. Is DNS resolving. Can you even reach port 443. Then look at the CDN or proxy config, then the automation that’s supposed to renew the cert. One of those is usually the culprit. And honestly, if the host shouldn’t be public anymore, just pull it off the list and shut the exposure down on purpose instead of letting it linger.
How early should I renew an SSL certificate?
Two to four weeks ahead, minimum. Once a cert expires, browsers throw up that full-page block and the site is just gone for visitors, so you want margin for the deploy that inevitably hiccups at the worst moment.
Why did my certificate expire if I use Let’s Encrypt auto-renewal?
Because auto-renewal fails quietly, which is the worst way to fail. The cron stops firing. The validation path breaks. Or the cert renews fine but the web server never gets reloaded to pick it up. You don’t notice any of that until the site’s already down. So watch expiry from the outside, separately, and a botched renewal turns into a heads-up instead of an outage.
Can I monitor several domains at once?
That’s the whole idea. Drop in every host, one per line, and you get days remaining for each cert side by side. The one about to lapse jumps right out at you.
