SSL certificate monitor

An SSL certificate monitor checks the TLS certificate served by each domain on a schedule, compares it to the last known state, and fires an alert when the expiry date crosses a configured threshold. The key distinction from a general-purpose monitoring tool is that it reads the X.509 certificate fields directly: the exact notAfter date, the issuer and CA chain, the Subject Alternative Names, the TLS version negotiated, and whether the chain terminates at a trusted root. A port-level check telling you that port 443 is open is not the same as knowing your certificate expires in 7 days.

Most outages caused by SSL certificates are entirely preventable — and they happen not because teams forgot to renew, but because the renewal ran but the new certificate was never deployed. Let's Encrypt auto-renewal writes a new certificate to disk but does not reload the web server. Nginx continues serving the old one. An SSL certificate monitor that reads CA records or CT logs will show the renewal as successful. An SSL certificate monitor that performs a genuine TLS handshake on port 443 will show the old certificate with its original expiry — which is the one your users are actually seeing.

Staged alert thresholds at 30, 14, 7 and 1 days give different levels of urgency different lead times. The 30-day alert is a heads-up to confirm auto-renewal is configured correctly. The 14-day alert means it is time to initiate a manual renewal if automation has not run. The 7-day alert is urgent. The 1-day alert is an emergency. Each threshold fires exactly once per certificate — idempotent delivery means you get one notification per crossing, not one per check cycle. Alert fatigue from repeated notifications is itself a monitoring failure.

Certificate Transparency monitoring runs alongside the live probe and provides a different signal. Every publicly trusted CA must log issued certificates to CT logs within 24 hours. When a new certificate appears in CT for one of your monitored domains — from your own renewal or from an unexpected issuance — an alert fires immediately. This matters for security: a mis-issued certificate (via a compromised CA or a social engineering attack on your registrar) will appear in CT before it can be exploited, giving you a short window to request revocation.

Fleet monitoring means covering every hostname, not just the main domain. The API subdomain, the internal admin panel, the staging environment that still gets real traffic, the partner integration endpoint — each has its own certificate, its own renewal timeline, and its own deployment pipeline. Certificate expiries on secondary subdomains are underreported precisely because they are out of the main monitoring view. CertFleet tracks each hostname independently, with separate expiry timelines and separate alert configurations.

Setup takes under a minute: enter a domain, choose alert thresholds and channels, and monitoring starts immediately. The free tier monitors 10 SSL domains with no time limit, email and Slack alerts, and CT monitoring included. Starter at $15/mo adds HMAC-signed webhooks, full REST API access, and 1-minute uptime checks. No infrastructure to deploy — CertFleet runs on Cloudflare Workers with an external probe, so there is nothing to install or maintain on your side.