SSL certificates expire. When they do, browsers show security warnings, search engines flag your site, and payment processors refuse to connect. An expired cert on a production service typically costs hours of engineer time and real revenue. The monitoring required to prevent this is free in most cases — the gap is usually just that it was never set up.
Before choosing a monitoring approach, it's useful to know where your certificates currently stand. Check any domain's expiry right now with the free SSL Certificate Checker — no account required.
Google Search Console will sometimes surface HTTPS errors in its Coverage and Security reports — including issues caused by expired or invalid certificates. If you already have Search Console set up for your site, it costs nothing extra and requires no additional configuration.
How to use it: In Search Console, go to Security & Manual Actions > Security Issues. If your site has a certificate error that Google has detected, it will appear here.
The real limitation: Search Console is a reactive signal, not a proactive alert. Google has to crawl your site, detect the error, index it, and surface it in the report. This typically happens after the certificate has already expired and affected users. You're learning about an outage that already happened, not preventing one.
Search Console is useful for confirming that a cert issue impacted Google's crawling — it's not a substitute for forward-looking expiry monitoring.
UptimeRobot's free plan includes 50 monitors with SSL certificate expiry tracking bundled in. When you add an HTTPS domain as an uptime monitor, UptimeRobot automatically checks the certificate and emails you 30 days before expiry.
Setup (5 minutes):
That's it. UptimeRobot will check your domain every 5 minutes for uptime and track the certificate expiry date, emailing you when it hits the 30-day threshold.
What you get on the free tier:
What you don't get on the free tier:
If you manage your own servers and use Let's Encrypt with certbot, you can set up a cron job that checks certificate expiry daily and emails you when any cert is within a configurable threshold. This gives you unlimited domains and configurable advance windows at zero cost beyond your server's existing operational overhead.
A minimal working script:
#!/bin/bash
# ssl-expiry-check.sh
# Run daily via cron; alerts when any domain cert expires within ALERT_DAYS
DOMAINS=("yourdomain.com" "api.yourdomain.com" "anotherdomain.com")
ALERT_DAYS=30
ALERT_EMAIL="ops@yourcompany.com"
for DOMAIN in "${DOMAINS[@]}"; do
EXPIRY=$(echo | openssl s_client -connect "$DOMAIN":443 \
-servername "$DOMAIN" 2>/dev/null \
| openssl x509 -noout -enddate 2>/dev/null \
| cut -d= -f2)
if [ -z "$EXPIRY" ]; then
echo "SSL check failed: $DOMAIN (could not retrieve cert)" \
| mail -s "SSL error: $DOMAIN" "$ALERT_EMAIL"
continue
fi
EXPIRY_EPOCH=$(date -d "$EXPIRY" +%s 2>/dev/null \
|| date -j -f "%b %d %T %Y %Z" "$EXPIRY" +%s)
DAYS=$(( (EXPIRY_EPOCH - $(date +%s)) / 86400 ))
if [ "$DAYS" -le "$ALERT_DAYS" ]; then
echo "$DOMAIN SSL expires in $DAYS days ($EXPIRY)" \
| mail -s "⚠️ SSL expiry warning: $DOMAIN ($DAYS days)" "$ALERT_EMAIL"
fi
doneAdd to crontab to run daily at 8am:
0 8 * * * /path/to/ssl-expiry-check.sh 2>&1 | logger -t ssl-checkWhere this breaks in practice:
mail command requires a working outbound mail setup — often broken or spam-filtered on cloud VMsA more reliable variant replaces mail with a webhook POST to a Slack channel or a generic HTTP endpoint, eliminating the mail server dependency entirely.
The lowest-tech approach: bookmark the SSL Certificate Checker with a reminder to check it monthly. Set a recurring calendar event — "check SSL certs" — and use the tool to verify each domain's expiry date when it fires.
This sounds almost too simple to be worth mentioning, but it has a real niche: environments where you can't install monitoring tools, don't have server access, or are managing only one or two domains for a non-technical client.
Why it works:
Why it fails:
SSLWatch is a dedicated SSL certificate monitoring tool currently in early access. The core value proposition is what the free tools miss: multiple alert thresholds (60 days, 30 days, 7 days, 1 day) instead of a single 30-day window.
The operational difference matters more than it sounds. A 30-day single alert gives you one shot to act. If you're traveling, the alert goes to your spam folder, or your renewal process takes longer than expected, you're suddenly at 0 days. Multi-window alerting means you have to miss multiple alerts across multiple weeks to end up with an expired cert.
The free SSL Certificate Checker is available now — check any domain instantly without creating an account. The paid tier (early access at $9/month) adds automated monitoring with multi-window email alerts.
What SSLWatch offers:
| Approach | Setup time | Alert advance | Domains | Reliable? |
|---|---|---|---|---|
| Google Search Console | 0 min (if set up) | Reactive only | Verified only | No — after-the-fact |
| UptimeRobot free | 5 min | 30 days | 50 | Yes — recommended |
| Self-hosted cron | 30–60 min | Configurable | Unlimited | Depends on setup quality |
| Browser bookmark | 2 min | Manual only | Any | No — requires habit |
| SSLWatch | 5 min | 60/30/7/1 days | Per plan | Yes — multiple windows |
For most developers: start with UptimeRobot free tier today. It takes 5 minutes, covers 50 domains, and the 30-day single-threshold alert is sufficient for most workflows. Do it now rather than setting up something more sophisticated later.
If you manage production systems where a missed alert is a real risk, or if 30 days isn't enough lead time for your renewal process: add SSLWatch for multi-window alerts on your most critical domains.
If you already have Prometheus infrastructure: use blackbox_exporter and set multiple alert thresholds at 60, 30, and 7 days. You have the stack; don't add a new vendor.
See exactly how many days remain on any domain's certificate — no account needed.
Free SSL checker SSLWatch early access