Your Certificate Expires. Your Site Goes Dark.

There is a specific kind of phone call that every business owner eventually gets. It comes from a customer, or a salesperson, or your own spouse, and it goes something like: “Hey, is your website down? I’m getting a big red warning page.”

You pull it up. Sure enough: NET::ERR_CERT_DATE_INVALID. Your SSL certificate expired at some point in the last few hours, and every browser on earth has decided your site is now a security threat.

Here is the part that stings. Nothing broke. Your server is running. Your database is fine. Your application code is exactly the way it was yesterday. A date passed, and a date is all it took.

An expired certificate is not a warning. It’s an outage.

Years ago, an expired certificate produced a scary-looking interstitial that a determined visitor could click past. That era is over.

Modern browsers hard-fail on certificate errors. If your site sends HSTS headers, and it should, there is no “proceed anyway” link at all. The visitor’s only option is to leave. Meanwhile:

• Search crawlers get the same error your customers do.
• Payment processors and webhooks refuse the TLS handshake outright. No retry, no queue, just failures.
• Mobile apps hitting your API stop working, and app-level certificate pinning can make the failure even harder to diagnose.
• Email stops flowing if the expired certificate was on your mail host rather than your website.

An expired certificate is a total outage with a completely preventable cause. It is arguably the dumbest way to lose a day of revenue, and it happens constantly, to businesses far larger and better staffed than yours.

“But we automated renewals.”

Good. So has almost everyone who has ever had a certificate expire on them.

Automation reduces the odds; it does not eliminate them. Let’s Encrypt certificates last 90 days, and the industry is moving toward even shorter lifetimes, which means renewal now happens often enough that a silent failure has many chances to bite you. The common ways it goes wrong:

• The renewal ran, but the reload didn’t. Certbot fetched a shiny new certificate and put it on disk. Nginx kept serving the old one from memory because the post-hook never fired.
• Validation quietly stopped working. Someone moved DNS, tightened a firewall rule, or added a redirect that broke the /.well-known/acme-challenge/ path.
• The cron job disappeared. A server migration, an OS upgrade, a rebuilt container image, and the timer that had been running faithfully for two years simply isn’t there anymore.
• Nobody owns it. The certificate lives on a load balancer, a CDN edge, an appliance, or a vendor-hosted subdomain that your renewal script has never touched.
• The alert email went to a person who left. Or to a distribution list nobody reads. Or straight to spam.

Automation is a process. Monitoring is proof the process actually worked. You need both, and only one of them tells you the truth.

“Valid” and “set up correctly” are different questions

Even a perfectly current certificate can be misconfigured in ways your own browser will never reveal, because your browser has cached intermediates from other sites you’ve visited and it papers over the gap for you. Your customer’s phone, on a fresh network, has no such cache.

The questions worth checking continuously:

Is the chain complete? If your server doesn’t send the intermediate certificates, some clients build the chain from cache and succeed while others fail outright. This is the classic “works on my machine, broken for a third of visitors” bug, and it’s invisible unless you test the way a stranger would.

Does the hostname actually match? A certificate covering example.com does nothing for www.example.com unless that name is in the SAN list. Adding a subdomain and forgetting to reissue is a weekly occurrence somewhere.

Did anything change that shouldn’t have? A new issuer, a rotated key, a domain name added or removed from the certificate. These can be perfectly routine, or they can be the first visible sign that something is wrong. You want to know which, and you want to know today.

What about everything that isn’t a website? Your mail server’s SMTP, IMAP, and POP certificates expire on exactly the same schedule as your web certificate, and they usually fail more quietly. Nobody sees a red page. Mail just stops.

Did somebody else issue a certificate for your domain? Every publicly trusted certificate gets written to public Certificate Transparency logs. Those logs are readable, which means it’s possible to know when a certificate carrying your name is issued by someone who isn’t you. That is either a forgotten vendor spinning something up, or it’s a problem, and both are worth a look.

Uptime monitoring: the other half of the same job

Certificates are one way a site goes dark. There are plenty of others: a full disk, a hung process, an expired domain registration, a bad deploy at 4:55 PM on a Friday.

The uninteresting truth about uptime monitoring is that its value is almost entirely in the check interval and the quality of the check. A monitor that pings once an hour will tell you about a 20-minute outage sometime next week. A monitor that checks every five minutes tells you while it’s still short enough to be embarrassing rather than expensive.

And a check that only asks “did the server return HTTP 200?” is thinner than it looks. Plenty of catastrophically broken pages return a cheerful 200: a database error rendered inside your normal template, a blank white page, a cached maintenance notice. Keyword checks fix this by looking for a string that only appears when the page has genuinely rendered. Add TCP checks for the services that don’t speak HTTP, and response-time tracking so you can see the slow degradation that precedes the actual failure.

Then there’s the part everyone forgets until they need it: a status page. When you’re down, your support channel floods with people asking the same question. A public status page answers it once, at a URL that stays up when your site doesn’t.

What good alerting looks like

Monitoring you don’t act on is just a very expensive logging system. The alerting layer is where most tools fall down:

• Warn early and repeatedly, not on the expiry date. A 30-day heads-up gives you a calm Tuesday afternoon to fix things. A same-day alert gives you a fire drill.
• Reach people where they actually are. Email, Slack, Teams, Discord, Telegram, Pushover, webhooks into your own systems, whatever your team genuinely reads.
• Escalate until someone acknowledges. A single notification at 2 AM that nobody sees is functionally identical to no notification at all.
• Suppress alerts during planned maintenance. The fastest route to an ignored monitoring system is one that cries wolf every time you deploy.
• Keep an audit trail. Certificate changes, alerts fired, sign-ins, administrative actions: who did what, and when. Invaluable during a post-mortem, and increasingly non-optional if you carry compliance obligations.

Announcing sslup.io, now available from JAMD Technologies

We built the tool we wanted to exist, and it’s live today: sslup.io, a new service from JAMD Technologies.

sslup.io watches certificate expiry and site uptime in one place, so you’re not stitching together two subscriptions and two sets of alerts to answer one question: is my site working right now, and will it still be working next month?

Certificate monitoring

• Expiry tracking with alert thresholds you set, checked daily on the free plan and hourly on paid ones
• Change detection for new issuers, rotated keys, and domains added or removed
• Full chain and hostname validation, so you know the certificate is installed correctly, not merely valid
• Certificate Transparency log monitoring to surface certificates issued for your names that you didn’t request
• Coverage for SMTP, IMAP, and POP over TLS, not just HTTPS

Uptime monitoring

• HTTP and TCP checks as often as every five minutes, with response-time history
• Keyword verification to confirm the page actually rendered
• Incident history with start time, duration, and cause
• 24-hour, 7-day, and 30-day availability figures
• A public status page you can point customers at during an outage

Alerting and administration

• Seven notification channels: Email, Slack, Teams, Discord, Telegram, Pushover, and webhooks
• Per-group, per-severity routing with escalation and repeat notifications
• Maintenance windows to keep planned work from generating noise
• Separate groups per client with isolated contacts and role-based access, built for anyone managing more than one organization’s infrastructure
• A full activity log of certificate changes, alerts, sign-ins, and administrative actions

AI analysis (paid plans) reviews a group of certificates and returns a written assessment: what to fix first, what the fleet looks like overall, and anything that doesn’t add up, prioritized by real business impact, so your production checkout server outranks a staging box nobody uses.

Pricing

Every paid plan starts with a free 14-day trial of the Business plan, and there’s no credit card required, so there’s nothing to cancel. When it ends you drop to the free tier rather than losing access: one certificate, watched indefinitely.

Frequently asked questions

What actually happens when an SSL certificate expires?
Browsers stop trusting the connection and show a full-page security warning instead of your site. If you send HSTS headers there is no way for a visitor to click through, so the site is effectively offline. APIs, webhooks, and payment integrations fail their TLS handshake at the same moment.

I use Let’s Encrypt with automatic renewal. Do I still need monitoring?
Yes. Automatic renewal fails silently more often than people expect: a reload hook that never fires, a broken validation path after a DNS or firewall change, or a cron job lost during a server migration. Renewal is the process; monitoring is the proof the process worked.

How early should I be warned before expiry?
Thirty days is a comfortable default, with escalating reminders as the date approaches. Alerting on the expiry date itself gives you an emergency instead of a task.

Can sslup.io monitor certificates that aren’t on a website?
Yes. It checks SMTP, IMAP, and POP over TLS in addition to HTTPS, which matters because mail certificates fail quietly and are easy to forget.

What does uptime monitoring add if I already watch certificates?
Certificates are only one way a site goes down. Uptime checks catch full disks, hung processes, bad deploys, and expired domains, with keyword verification so a broken page that still returns HTTP 200 doesn’t slip past.

How is this different from running my own expiry script?
A script on one server tells you about the certificates that server knows about. sslup.io checks from the outside, the way a customer does, covers endpoints you don’t control, reads Certificate Transparency logs, and keeps alerting until a human acknowledges.

Is there a free option?
Yes. The free plan monitors one certificate indefinitely with daily checks and email alerts, no credit card required.

Start with the one that would hurt most

If you take nothing else from this: go look up when your main certificate expires. Right now, in another tab. Most people are surprised by the answer, and a meaningful number find something they’d stopped thinking about years ago.

Then put a monitor on it, so you never have to check manually again.

Get started at sslup.io

sslup.io is a service from JAMD Technologies, 30+ years of solving business problems with technology. Questions about monitoring your infrastructure, or need something more custom? Get in touch.