SSL Certificate Expiry Monitoring: Never Get the "Your Connection Is Not Private" Surprise (2026)

Updated August 31, 2026 · 6 min read

Why expired certificates keep taking websites down

When a TLS certificate expires, browsers don't show a gentle warning — they put up a full-page red screen ("Your connection is not private") and many visitors leave immediately. API clients start rejecting requests. Mobile apps that pin certificates can stop working entirely.

The pattern behind nearly every incident is the same:

• The cert was installed once and forgotten.
• Auto-renewal was never configured — or silently broke after a DNS change, server migration or ACME account issue.
• Nobody had a reminder tied to the actual certificate, only a calendar entry from last year that no longer exists.

Even with Let's Encrypt's 90-day certificates, renewal failures are common enough that certificate expiry remains a top-five cause of avoidable downtime for small and mid-size sites.

Step 1: Check your expiry dates right now

On any Mac or Linux machine:

echo | openssl s_client -servername yoursite.com -connect yoursite.com:443 2>/dev/null \
  | openssl x509 -noout -dates -issuer -subject

This prints notBefore and notAfter — the dates that matter. Do this for every domain and subdomain you run, including staging and API hosts. Don't forget certificates on mail servers or load balancers, which browser visitors never see but other systems depend on.

Step 2: Fix auto-renewal properly

If you use Let's Encrypt / Certbot, verify renewal actually works instead of assuming it does:

certbot renew --dry-run

If it fails, fix it today. Common causes: the HTTP-01 challenge path is blocked, the DNS record points somewhere else since a migration, or the cron/systemd timer was disabled. If you're on Cloudflare or another proxy with origin certificates, note those have long lifetimes but still expire — and they won't renew themselves.

Step 3: Monitor expiry independently of renewal

This is the step most teams skip. Auto-renewal can break at any time; monitoring tells you before the expiry date whether something went wrong. You want alerts at roughly 30, 14 and 7 days before expiry — early enough to react calmly.

What to look for in a monitoring setup

• Coverage of all hosts — not just the main domain. Wildcard and multi-SAN certs cover several names; make sure each name is checked.
• Days-until-expiry thresholds, not just "expired" alerts. An "expired" alert is an outage report; a 30-day alert is a task.
• Chain validation — an incomplete chain shows as broken in some browsers even while the leaf cert is valid.

How DeskUptime handles it

DeskUptime runs on your Mac or Windows PC and re-checks every monitored URL on your schedule — as often as every minute if you want. Each HTTPS check validates the certificate chain and tracks days until expiry, so a soon-to-expire cert shows up in the dashboard long before browsers block anyone. Because it runs locally, there's no per-monitor pricing and no data about your infrastructure sent to a third party.

npx github:mahope/deskuptime check https://yoursite.com

The CLI above gives you an instant health report including certificate status; the desktop app adds continuous scheduling and notifications.

Quick checklist

1. List every hostname you serve over HTTPS (including internal ones).
2. Check each cert's notAfter date with openssl.
3. Run certbot renew --dry-run (or your platform's equivalent).
4. Set up independent expiry monitoring with 30/14/7-day warnings.
5. Add cert checks for staging and API hosts too — customers aren't the only ones who break.

Certificate expiry is the cheapest outage to prevent: the date is printed on the certificate itself. All that's missing is something watching it.