Common questions about Certificate Monitoring answered.
Any SSL/TLS certificate reachable over the network: any CA, self-signed, wildcard, or SAN. Direct TLS on any port, plus STARTTLS for SMTP, IMAP, POP3, LMTP, LDAP, and FTP.
Alerts fire at thresholds you configure, anywhere from 0 to 90 days out. Each alert carries certificate details and recommended actions via email, Slack, SMS, webhooks, and more.
Yes. Leaf, intermediates, and root are all validated. Missing or expired intermediates cause the same browser warnings as an expired leaf, so we alert on any chain issue.
Yes. Lightweight Docker agents run on-premise to monitor internal CAs and self-signed certs without exposing the network. Learn about private network monitoring
Yes. Any port, including STARTTLS protocols (SMTP 25, IMAP 143, POP3 110, LMTP 24, FTP 21, LDAP 389) and implicit TLS variants (SMTPS 465, IMAPS 993, POP3S 995, FTPS 990, LDAPS 636).
Yes, and monitoring matters most here. ACME renewals fail silently: a broken cron, a failed DNS challenge, or a changed server leaves an expired certificate in place with no warning. We verify the certificate itself, not the renewal job.
Eight independently configurable alert types: expiration, hostname mismatch, CA trust failure, chain integrity, connection failures, missing or misconfigured CAA records, fingerprint changes, and certificate flapping.
Monitoring Profiles group hosts with shared settings: alert thresholds, alert types, private CA assignments, and agent routing. A "Production" profile can page on-call via PagerDuty while "Staging" uses email-only.
Yes. The REST API and GitHub Action verify certificates after deploys, register new domains automatically, and trigger webhooks for downstream automation.
We are dedicated to certificate monitoring: STARTTLS coverage, internal CA agents, CAA validation, and per-host daily billing. vs. UptimeRobot ยท vs. TrackSSL
Our support team is ready to help.