Docs

Read probe failures without decoding TLS by hand.

Domain Trust Watch keeps failure classes separate so the right person starts with the right layer.

Reading path

Guidance turns into setup

Next steps

Articles connect the operational decision to checker, docs, monitoring, and routing workflows.

CheckRun one hostname now
LearnRead certificate monitoring docs
RouteSend urgent warnings
Event review

Failure context, review state, and delivery attempts stay together.

Event review separates the certificate failure, payload summary, routed alert attempts, and human acknowledgement path.

01

DNS failures

A DNS failure means the hostname could not be resolved from the checker. Start with DNS records, recent zone changes, nameserver health, and whether the hostname should exist publicly.

  • Check whether the hostname exists in public DNS.
  • Review recent zone edits, delegation changes, or nameserver outages.
  • Confirm the monitor is using a public hostname, not an internal-only name.
Probe failure routing
SymptomLikely layerFirst checkLikely owner
DNS failureDNSPublic records, nameservers, delegation, recent zone edits.DNS owner, registrar, hosting provider.
TCP failureNetwork reachabilityPort, firewall, CDN proxy, load balancer listener.Network, platform, hosting, or CDN owner.
TLS handshake failureTLS listenerSNI, protocol, cipher, mTLS, non-TLS service on port.Load balancer, ingress, or server owner.
Hostname mismatchCertificate identitySAN list, SNI hostname, CDN or load balancer certificate binding.Certificate or platform owner.
Expired or not yet validCertificate validityRenewal status, deployment target, service reload, system time.Renewal and deployment owner.
Untrusted chainTrust pathIntermediate bundle, chain order, issuer trust, origin versus edge certificate.Server, CDN, or certificate owner.
Parse errorCertificate formatServed certificate format, PEM bundle, proxy behavior.Server or platform owner.
02

TCP failures

A TCP failure means the probe could not connect to the configured host and port. Check firewall rules, load balancer listeners, CDN configuration, port selection, and whether the service is reachable from the public internet.

  • Confirm the selected port is expected to accept TLS.
  • Check public firewall, load balancer, and CDN listener configuration.
  • Verify whether the endpoint is intentionally private or region-restricted.
03

TLS handshake failures

A TLS handshake failure happens before certificate validation completes. Common causes include non-TLS services on the configured port, unsupported protocol configuration, SNI mismatch, or a broken TLS listener.

04

Certificate validation failures

Hostname mismatch, expired, not-yet-valid, untrusted chain, and parse errors are certificate problems. Treat name mismatch and expiry as critical because clients can reject the connection even when the server is reachable.

  • Check SAN coverage when the hostname does not match.
  • Check deployment state when the certificate is expired or not yet valid.
  • Check intermediates and issuer trust when the chain is untrusted.
FAQ2 answers
  1. Is a TLS handshake failure the same as an expired certificate?

    No. A TLS handshake failure means the checker could not complete TLS negotiation. An expired certificate is a validation failure after a certificate can be read.

  2. What should I check first for hostname mismatch?

    Check the certificate SAN list, SNI hostname, CDN or load balancer certificate binding, and whether the public hostname points at the expected endpoint.

Check the hostname

Run a live check before changing monitor settings.

The checker separates DNS, TCP, TLS, hostname, trust-chain, active-window, and expiry problems for one public hostname.