Why monitor?

Certificate and domain failures are usually predictable, but they are easy to miss because the deadline belongs to infrastructure rather than to the application feature being shipped. Independent monitoring turns a silent date and a hidden deployment assumption into a visible, actionable signal.

What can go wrong

• A certificate expires while the renewal job is broken, misconfigured, or pointed at the wrong host.
• A server presents the wrong certificate after a load-balancer, proxy, or deployment change.
• A certificate chain is incomplete even though the leaf certificate itself is still in date.
• A domain registration expires separately from the certificate served by that domain.
• A renewal succeeds at the certificate authority but the new certificate never reaches production.

Why external monitoring helps

A renewal system can report success from inside the deployment environment while users still receive an old, incomplete, or unexpected certificate. CertWatch connects from outside the system being monitored and checks the certificate actually presented for the hostname and port, including the chain and certificate identity. It also checks domain registration signals independently through RDAP.

Monitoring is a safety net, not a renewal system. It tells you what an external client can see and gives you time to investigate; it does not install certificates, renew domains, or prove that private-network services are healthy.

What to monitor first

1. Public TLS endpoints that customers, APIs, or mail clients depend on.
2. Domains whose registration expiry would interrupt service or make recovery difficult.
3. Non-HTTP TLS services such as SMTP, IMAP, databases, and API ports.
4. Targets with a history of manual renewal or multi-layer proxying.

Use the free tools to inspect one target, then follow the setup guide to keep watching it.