SSL Certificate Monitoring & Expiry Guard

Why automated renewal is not enough

Most teams assume that installing an ACME client solves certificates forever. In practice, renewal is a pipeline with several independent failure points, and only the last one is visible to your users.

The certificate can renew successfully on disk while the running process continues serving the old one because nothing reloaded it. A load balancer can hold a stale copy. A wildcard certificate can renew for the apex domain while a subdomain quietly falls out of the SAN list. Each of these produces a valid renewal log and a broken site.

• Renewed but not reloadedThe new certificate exists on disk; the process is still serving the expired one from memory.
• Renewed on one nodeA single node in a pool missed the deploy and serves an expired cert to a fraction of traffic.
• DNS challenge brokeA DNS provider change silently invalidated the validation method months before expiry.
• Chain regressionThe leaf is valid but an intermediate was dropped, so stricter clients reject the connection.

What SutramX checks

On every HTTPS check, the probe inspects the certificate actually presented on the wire — not what your configuration claims should be there. That distinction is the whole point: it is an end-to-end observation from outside your infrastructure.

The observed certificate is parsed for its subject, SANs, issuer, and validity window. The chain is validated to a trusted root. If the hostname being monitored is not covered by the presented certificate, that is reported immediately rather than waiting for the expiry ladder.

The escalation ladder

Warnings are staged so that early notice goes to a low-urgency channel and late notice goes everywhere. Thirty days out is an email and a dashboard flag. Seven days out is a real alert. One day out is treated with the same severity as a partial outage, because that is what it is about to become.