SSL Certificate Monitoring: How to Get Alerted Before Your Cert Expires

What happens when an SSL certificate expires

When a TLS certificate expires, browsers immediately block access to your site with a full-page security warning: “Your connection is not private” in Chrome, “Warning: Potential Security Risk Ahead” in Firefox. Users can't click through without manually overriding the warning — and most won't.

The impact is immediate and severe: revenue stops, support tickets spike, and your Google ranking can drop if Googlebot can't crawl your site. The fix — renewing the certificate — takes anywhere from 30 seconds (for automated Let's Encrypt renewal) to several hours (for OV/EV certificates that require identity verification).

The worst part: expiry is entirely predictable and preventable. You know exactly when a cert expires. You just need a system that tells you before it happens.

How SSL certificate monitoring works

An SSL monitoring tool connects to your server via TLS, reads the certificate's notAfterfield, and compares it to today's date. If expiry is within the alert window (typically 14–30 days), it sends you an email.

A good uptime monitor does this on every probe — not just on a daily schedule. This means if a certificate is replaced with an invalid one (wrong domain, expired chain, self-signed), you find out within minutes rather than waiting for the next daily check.

SitePulse checks your SSL certificate on every HTTP probe. For a monitor set to 1-minute intervals, that's 1,440 certificate checks per day per monitor. If anything changes — cert replaced, expiry date shifted, domain mismatch — you get an alert.

Common SSL failure modes (beyond expiry)

1. Auto-renewal failure

Let's Encrypt certificates expire every 90 days and are designed to auto-renew at 60 days. Renewal fails when:

• Your DNS doesn't resolve correctly when the renewal runs
• HTTP-01 challenge is blocked by a firewall or redirect rule
• CAA DNS records don't authorize Let's Encrypt
• Your server's certbot or acme.sh job fails silently

Hosting providers (Vercel, Netlify, Render, Railway) handle Let's Encrypt for their domains, but custom domain auto-renewal can fail silently. An external monitor is your safety net.

2. Certificate domain mismatch

A cert issued for example.com doesn't cover www.example.com unless the cert uses a Subject Alternative Name (SAN) for both. A cert for *.example.comcovers all subdomains but not the root domain. Monitoring catches this the moment it's deployed.

3. Intermediate certificate chain issues

Your server might have a valid leaf certificate but be missing the intermediate CA certificates in the chain it presents. Most browsers cache intermediates and handle this gracefully, but some clients (curl with strict verification, older Android versions, IoT devices) reject incomplete chains. An external monitor using strict TLS verification catches this.

4. Mixed content

An HTTPS page loading HTTP resources (images, scripts, fonts) triggers browser mixed-content warnings. Modern browsers block active mixed content silently. This isn't an SSL expiry issue, but it shows up as a security warning to users. Regular uptime monitoring with keyword checking can catch cases where your CDN or image host switched from HTTPS to HTTP.

How to set up SSL certificate monitoring

Option 1: Use SitePulse (recommended)

SitePulse checks SSL on every HTTP probe. Setup takes under 60 seconds:

1. Sign up at sitepulse.satosushi.co (free, no credit card)
2. Add your production URL
3. SSL monitoring is automatic — no separate configuration
4. You get an email 14 days before your cert expires

The free plan covers 5 monitors. That's enough for most side projects and small SaaS apps (homepage, API health, main subdomain).

Option 2: Cron job with openssl

For self-hosted setups, you can check expiry with:

#!/bin/bash
DOMAIN="yourdomain.com"
EXPIRY=$(echo | openssl s_client -connect $DOMAIN:443 -servername $DOMAIN 2>/dev/null \
  | openssl x509 -noout -enddate | cut -d= -f2)
EXPIRY_EPOCH=$(date -d "$EXPIRY" +%s)
NOW=$(date +%s)
DAYS_LEFT=$(( (EXPIRY_EPOCH - NOW) / 86400 ))

if [ $DAYS_LEFT -lt 14 ]; then
  echo "SSL cert for $DOMAIN expires in $DAYS_LEFT days" | mail -s "SSL Alert" you@example.com
fi

Schedule this as a daily cron job. The downside: you're responsible for maintaining it, and it only runs once per day.

Option 3: Uptime Kuma (self-hosted)

Uptime Kuma is a popular open-source uptime monitor with SSL checking. It requires a VPS to run and Docker to deploy, but it's free and gives you full control. Good option if you're comfortable managing your own infrastructure.

What to monitor

Add a monitor for every production hostname your users reach:

• Your main domain (yourdomain.com)
• WWW subdomain (www.yourdomain.com) if you serve traffic there
• App subdomain (app.yourdomain.com)
• API subdomain (api.yourdomain.com)
• Any customer-facing subdomain

Don't bother monitoring internal hostnames, staging environments (unless customers access them), or hostnames managed by your CDN provider (Cloudflare, Fastly) — their certificates are managed separately and rarely expire.

14 days is the right alert window

14 days gives you enough time to renew manually if auto-renewal fails, get help from your hosting provider, or work through the process for OV/EV certificates that require identity verification. 30 days is better for high-stakes production systems with bureaucratic renewal processes.

Anything longer than 30 days creates alert fatigue — you'll start ignoring the emails. Anything shorter than 7 days risks missing the window if you're traveling or on vacation.