TLS certificate expiry: the outage that never had to happen

Every few months a bank, an airline or a government portal goes dark because a TLS certificate lapsed. Nothing was hacked, no code shipped, no server failed. Someone missed a renewal date, and every visitor saw a full-page browser warning instead of the site.

It is the cheapest outage in the catalogue to prevent, and one of the most common to suffer.

Why it keeps happening

A certificate is a piece of infrastructure with an expiry date and no owner. It was installed by a contractor in 2023, renewed by someone else in 2024, and this year nobody is quite sure who is responsible.

Three things make it worse:

  • Renewals are silent. Nothing tells you that a renewal failed. Auto-renewal via ACME is excellent until a DNS challenge breaks after a provider migration, and then it fails quietly.
  • Browsers fail loudly, customers leave quietly. A warning page is a hard stop. Research consistently shows most visitors never click through.
  • The failure mode is binary. Unlike a slow disk or a filling queue, there is no degraded state to notice. It works, and then it does not.

What to actually monitor

A useful certificate check answers four questions:

  1. Does the TLS handshake succeed at all on the port you expect?
  2. When does it expire, in days?
  3. Does the certificate match the hostname you think it serves?
  4. Who issued it, in case a staging issuer is serving production traffic?

The third point catches a surprisingly common incident: a reverse proxy with no ServerName match serving the default certificate for a different domain. The site "works" in a browser that already has an exception, so nobody notices until customers complain.

Set the warning window to the renewal process, not the certificate

The single most useful setting is not the check interval, it is the warning threshold. Set it to slightly more than the time a renewal realistically takes inside your organisation:

  • Automated ACME renewal: 7 days is generous, 48 hours is enough.
  • Manual renewal through a Kenyan reseller or a finance approval step: 14 to 21 days, because that is how long the paperwork takes.
  • Certificates tied to a change window or a maintenance contract: 30 days.

A warning that fires with two days left is not a warning. It is an incident.

Daily checks are usually enough, with one exception

Certificates change weekly, not minutely, so a six-hour or daily check is the right cadence and keeps the cost trivial. The exception is the first few days after a renewal: a bad chain or a wrong key only shows up when the new certificate is actually served. A short burst of more frequent checks immediately after renewal catches a broken rollover while the old certificate is still in a backup.

How PIMA handles it

PIMA has a dedicated tls monitor type. It completes a real handshake, reads the leaf certificate, and reports separately on expiry, hostname mismatch and time-to-expiry. It also records the expiry date on every check, so you can see the countdown in the dashboard rather than discovering it in an alert.

Because it reports state changes rather than every check, you get one notification when a certificate enters the warning window and one when it is renewed. Not a daily reminder that nobody reads.

Next: what an hour of downtime actually costs.


← All posts