Certificate Expiry — Days Left on What You Are Actually Serving
This connects to a host over TLS and reports the expiry date of the certificate it presents. The distinction that matters is between the certificate you issued and the certificate that host is serving: those are the same thing only if deployment worked everywhere, every time. Checking the live endpoint rather than your certificate store is the whole point.
Why run it
An expired certificate is a complete outage with a security warning attached, and it arrives on a date that was known months in advance. The reason it still happens constantly is that renewal and deployment are separate steps: a certificate can renew perfectly in your ACME client and never reach the load balancer, or reach three of four servers, leaving one host serving the old certificate to a fraction of traffic. Only a check against the live endpoint sees that.
Why automate it
This is the single strongest case for automation in this catalogue, because the failure is both certain and silent. Automated renewal turns a recurring manual task into a background process, and the failure mode of a background process is that it stops without telling anyone — cron removed, credentials rotated, a DNS challenge that no longer resolves, a disk full. Everything looks fine until the last valid day. A scheduled check with staged alerts at thirty, fourteen and seven days is what converts that into a ticket, and it must run against every hostname, because the one nobody remembers is the one that lapses.
What it gives you
Independent verification that renewal is genuinely working, on every host, rather than confidence that it should be. It removes an entire category of self-inflicted outage for the cost of a daily connection.