Monitoring

SSL Certificate Monitoring

The SSL monitor reads the certificate on any host and port, and alerts you when the days remaining fall below your threshold, well before visitors see a browser warning.

Why certificate expiry matters

An expired certificate replaces your site with a full-page browser warning that the connection is not private. Most visitors leave, and many assume the site has been compromised.

Expiry is usually an administrative oversight, but the impact is immediate and reaches every visitor at once.

A certificate countdown crossing the warning threshold before expirycertificatewarn hereexpirytoday

Alerts before expiry

An uptime check only reports a problem after the certificate has expired. The SSL monitor fails while the certificate is still valid, as soon as the days remaining drop below your threshold.

A threshold of 30 days is a good default. It turns renewal into routine work rather than an emergency.

Certificates beyond the website

The certificates that expire unnoticed are often not on the website. They are on mail servers on ports 993 and 587, or on databases with TLS enabled on port 5432.

Browsers never warn about these, so the first sign is clients failing to connect. You can monitor any host and port, not only 443.

Verify automatic renewals

Automatic renewal can fail without warning: a renewal timer stops, a validation challenge starts failing after a firewall change, or a renewed certificate is written to disk while the server keeps serving the old one.

The SSL monitor checks the certificate actually being served, whoever issued it, including certificates on third-party services, older servers and internal certificate authorities.

Where Certbot was set up with the platform’s own playbooks, the Check Certificate Renewal playbook also runs a renewal dry run against Let’s Encrypt’s staging environment and confirms the renewal timer and the nginx reload hook. The monitor remains the check on what visitors are actually served.

What the check verifies

The check reads the certificate the host presents and looks at its expiry date. It does not fail because a certificate is self-signed or issued for a different name, so it can still report on those certificates.

Nothing is sent over the connection and no response is read. The certificate is inspected, not trusted.

Choosing a threshold

Match the threshold to your renewal process. If renewing means raising a ticket with another team, 30 days may not be enough.

Monitor mail and database certificates too. They are the ones most often forgotten.

Check daily. The days remaining change once a day, so more frequent checks add nothing.

Frequently asked questions

How far in advance can it warn?
Between 1 and 180 days. A longer window would leave normally renewed certificates permanently in a warning state.
Can it check certificates on ports other than 443?
Yes. Enter the host and the port, for example your mail server on port 993. Mail and database certificates are often the ones that expire.
My certificates renew automatically. Do I still need this?
Yes. It checks the result, not the renewal process. When the monitor is attached to a server, Auto-Fix reloads the web server if a renewed certificate is on disk but not yet being served.
Does it fail on self-signed certificates?
No. It reports on expiry. Refusing self-signed certificates would stop it reading them at all.
What happens if the certificate has already expired?
The check fails and reports the expiry date and how long ago it passed.

Key points

  • Alerts while there is still time to renew
  • Any host and port: web, mail or database
  • Threshold of 1 to 180 days per monitor
  • Reports on expired and self-signed certificates
  • Checked daily

Related features