SutramX inspects the SSL/TLS certificate actually served on every HTTPS check: issuer, hostname coverage (CN and SANs), the chain to a trusted root and the days left before expiry. Switch on expiry reminders for any HTTP or API monitor, on every plan including Free, and it warns you 30 days ahead by default, then 15, 7 and 2 days and 24 hours before expiry.
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 you get early notice with time to act, and repeated reminders as the deadline gets closer. Expiry warnings go to the monitor's email recipients and your connected chat and webhook channels: a first notice 30 days ahead by default (adjustable from 1 to 90 days), then at 15 days, 7 days, 2 days, and 24 hours before expiry, and again for the first few days after expiry if the certificate was not replaced. Once a certificate has actually expired, HTTPS checks fail TLS verification and open an incident through your normal alert channels.
Specifications
| Warning thresholds | First notice 30 days ahead by default (1-90), then 15, 7, and 2 days and 24 hours before expiry, plus post-expiry reminders |
|---|---|
| Chain validation | Leaf, intermediates, and trusted root |
| Hostname coverage | CN and SAN matching against the monitored host |
| Reported fields | Issuer, subject, SANs, valid-from, valid-to, days remaining |
| Setup required | Enable reminders per HTTP/API monitor |
| Delivery | Email, plus your connected chat and webhook channels |
Learn more
- Guides: Preventing SSL Expiry Outages and Domain Expiry Monitoring
- Free tools: SSL Expiry Checker
- Use cases: Monitoring for E-Commerce
- Comparisons: SutramX vs Freshping
- Documentation: SSL & domain expiry