Why monitor SSL certificates

When an SSL certificate expires, the browser blocks the connection entirely. There is no graceful degradation: the site or API is simply unreachable to any client enforcing certificate validation — which, in 2025, is every browser, every mobile app, and every server-to-server HTTP client. An expired certificate on a payment endpoint, an authentication API, or a health-check route triggers immediate on-call escalation and, depending on the audience, direct revenue loss within minutes.

Let's Encrypt popularised 90-day certificates and automated renewal, but automation is not infallible. The most common failure pattern is: auto-renewal succeeds, the new certificate is written to disk, but the web server is not reloaded to pick it up. The server continues to serve the old certificate until it expires. Since the renewal was 'successful' from the CA's perspective, no alert fires — until the old cert hits its expiry date and production goes down. A live TLS probe catches this because it reads what the server actually serves, not what was issued.

Certificate lifetimes are getting shorter. The CA/Browser Forum has voted to reduce maximum validity from 398 days (TLS 1.3 era) to 90 days, and proposals on the table would take it to 47 days. With 47-day certificates, each domain needs a fresh renewal every 5–6 weeks. At scale — 50 domains across staging and production — that is over 400 renewals per year. Any gap in automation coverage becomes a much higher-frequency risk. Monitoring catches the gaps; it does not replace automation but verifies that automation is working.

Certificate Transparency logs expose a different category of risk: mis-issuance. Public CAs are required to log every certificate they issue. If a CA is compromised, deceived, or makes an error, a certificate might be issued for your domain without your knowledge or authorization. An attacker with such a certificate can perform person-in-the-middle attacks on your users, intercept traffic, and impersonate your service. Watching CT logs for your domains surfaces these certificates within minutes of issuance — long before they can be deployed and used against you.

Organisations running internal PKI (self-signed or private CA certificates) face the same expiry risks without the safety net of public CT logs. Internal certificates for internal services, VPN endpoints, and mutual TLS between microservices have historically been managed with spreadsheets or tribal knowledge. When the engineer who remembers the expiry date leaves the company, the spreadsheet rots. Monitoring these certificates — via a probe that can reach the private endpoint — closes this blind spot.

The business case for SSL monitoring is straightforward: the cost of a missed renewal is a production outage measured in minutes or hours; the cost of monitoring is measured in dollars per month. For a payment API or a customer-facing SaaS, even 15 minutes of downtime due to an expired certificate costs far more than a year of monitoring subscription. The ROI calculation is trivial. The harder question is why monitoring is not already the default.

Manual processes break at scale and under organisational pressure. Renewals that were 'someone's job' fall through the cracks during team changes, holidays, or concurrent incidents. Automated renewal that was set up by a developer who has since left may have been reconfigured or broken by a system update without anyone noticing. Monitoring is the independent verification that the renewal system — whatever it is — actually worked.

CertFleet makes SSL monitoring a one-minute setup: add a domain, configure email or Slack alerts, and get staged notifications at 30/14/7/1 days before expiry plus immediate CT mis-issuance alerts. Test it with a free instant check on any domain, or see pricing — five domains and five uptime monitors are free forever, no credit card.