TLS certificate expiry monitoring

Why certificates still expire

Most certificates today are renewed by software, through the ACME protocol that Let's Encrypt and other certificate authorities use. That works until something around it changes, and the failure is silent:

• The renewal job stopped. A server was rebuilt without the timer, a container image dropped the client, or the job fails on an expired API token.
• The challenge no longer passes. The certificate authority must reach a file on your site or a DNS record. Moving DNS providers, putting a CDN or firewall in front, or redirecting port 80 can break that.
• The new certificate isn't served. Renewal wrote new files, but the web server, load balancer or proxy still holds the old certificate in memory until it reloads.
• A host nobody remembers. An API subdomain, a mail server, a staging site or a second load balancer with its own certificate, outside the automation.
• A certificate bought by hand. Renewed once a year by a person, or a payment card, that has since gone.

What happens when one expires

Browsers show a full-page warning instead of your site, and most visitors leave. Apps and API clients refuse to connect, usually with an error that says nothing to the person using them. Webhooks that other services send to you start failing on their side. None of this shows in your server's logs as an error, because the connections never complete.

Lifetimes are getting shorter

The CA/Browser Forum, where certificate authorities and browser makers set the rules for public certificates, has voted to shorten the longest a public TLS certificate may be valid in steps, down to 47 days in 2029. More renewals mean more chances for one to fail, and less time between a failed renewal and the expiry. Watching the date from outside matters more each year, not less.

What to watch

• The certificate actually served, checked from outside like a visitor would, not the file on disk. Only that catches a server that never reloaded.
• Every hostname and port that has one: the website, the API, the mail server's TLS ports, anything customers or partners connect to.
• The whole chain. A server sends its own certificate and the intermediate ones that lead to a trusted root. The earliest expiry among them is the one that counts.
• Validity, not only the date. A certificate for the wrong hostname, or one a browser doesn't trust, fails visitors just the same. An uptime check that verifies the certificate catches those the moment they appear.

When to be told

ACME clients usually renew well before the last weeks; a common default is about 30 days before expiry. So a certificate with two weeks left already means renewal has failed for a while, and that is the moment to hear about it: early enough to fix the automation calmly, during working hours.

A second, urgent reminder a week before expiry is the safety net, for when the first one was read and forgotten. Two warnings are enough. A daily reminder for a month teaches people to ignore it.

When you get the warning, renew by hand first if expiry is close, then find out why the automation didn't run. Otherwise it happens again at the next renewal.

How BBoxProbe handles it

• Every HTTPS monitor, and every TCP monitor with Connect with TLS, reports when its certificate expires: the earliest expiry among the certificates the server presents, as seen from the monitor's cities.
• With less than 14 days left you get a notice; if it still hasn't been renewed with 7 days left, an urgent one replaces it. When the certificate is renewed, a last notice says until when the new one is valid.
• Verify the TLS certificate is on by default, so an expired or untrusted certificate also fails the check itself and counts toward the monitor being down.

How it works lists every alert, and the integrations page shows where they can go.