Monitoring · playbook

SSL certificate monitoring.

Four approaches, when each one fits, and the failure modes that catch most teams. Plus a free scan to see your current exposure.

By MachineCert Engineering · Updated 2026-05-27

Quick answer

SSL certificate monitoring is the continuous tracking of TLS certificates across your infrastructure to catch expiry, misconfiguration, and revocation before they become outages. The four common approaches are endpoint scanning (TLS handshakes against known hostnames), Certificate Transparency log monitoring (passive, catches certs you didn’t know existed), agent-based collection (deep visibility on managed hosts), and observability platform integration (Datadog, Prometheus, Grafana). Most teams need two or three of these in combination.

Run a scan in 60 seconds
Our hosted scanner is coming soon. In the meantime, run a quick check with the free industry-standard tool:
Run a scan with SSL Labs
Approach 01

Endpoint scanning.

Open a TLS handshake against each known hostname, pull the leaf certificate, parse expiry and chain validity, and alert if anything is wrong. This is what most homegrown scripts and budget monitoring tools do, and it is the right baseline for public-facing endpoints.

The blind spot is everything not on your hostname list — internal services on private DNS, ephemeral certs inside Kubernetes pods, certs issued by an internal CA that you forgot existed. Endpoint scanning catches certs that already serve traffic; it misses the cert that’s about to.

Approach 02

Certificate Transparency log monitoring.

Every publicly trusted certificate is logged to one or more Certificate Transparency (CT) logs. Subscribe to your apex domains in a CT log monitor (crt.sh, Cloudflare’s Merkle Town, internal tooling) and you get a passive feed of every cert ever issued for your hostnames — including ones a former engineer created last quarter and forgot to document.

CT only catches publicly trusted certs. Internal PKI and self-signed certificates are invisible to it. Pair CT monitoring with endpoint scanning to cover both surfaces.

Approach 03

Agent-based and integration-based collection.

Lightweight collectors read certificate metadata directly from the systems that own it: Kubernetes (via cert-manager CRDs), AWS ACM, Azure Key Vault, GCP Certificate Authority Service, HashiCorp Vault, internal PKI databases. This is the only approach that sees ephemeral and internal certs reliably.

Observability platforms (Datadog, Prometheus, Grafana, New Relic) can ingest cert metadata as a metric and alert on expiry. This works when an existing platform is already deployed; it stops being economical once cert inventories grow past a few hundred unique certs.

Why MachineCert

Monitoring is step one. Renewal is step two.

SolarWinds and Datadog tell you a cert is about to expire. They don’t renew it. UptimeRobot pings an endpoint; if it answers, the page goes green — even when the cert behind it is expiring in 14 days. TrackSSL focuses on expiry tracking but leaves renewal to you.

MachineCert combines all four monitoring approaches — endpoint scanning, CT log monitoring, native cloud and Kubernetes integration, observability webhooks — with automated renewal across every CA you use, and a Trust Graph that shows blast radius before approval. Monitoring without renewal is an alert at 3am; monitoring with renewal is an outage that didn’t happen.

Start freevs SolarWindsvs Datadog

Monitor every cert.
Renew them automatically.

Free forever for up to 250 certificates · No credit card