How to monitor

How to monitor SSL certificate expiry

Expired TLS certificates cause instant, total outages — and they're completely preventable. Here's how certificate expiry monitoring works and how to set it up in minutes.

StatusCat3 min read

An expired TLS certificate is one of the most avoidable outages there is — and one of the most brutal. The moment it lapses, every browser shows a full-page security warning and your site is, for all practical purposes, down. No 500 error to debug, no partial degradation. Just a wall.

The good news: it's 100% preventable with a check that takes two minutes to set up.

Why certificates expire on you

Certificates have a fixed lifetime — 90 days for Let's Encrypt, up to about a year for commercial ones. They're supposed to auto-renew, and usually do. Expiries still happen because renewal is a pipeline, and pipelines break quietly:

  • A renewal cron job stops running after a server migration.
  • The ACME/DNS challenge fails because a record changed.
  • A rate limit or an API outage blocks the renewal.
  • The certificate lives on a load balancer or appliance nobody remembers owning.

In every one of these cases, auto-renewal fails silently. You don't find out until the certificate is already dead — unless you're monitoring for it.

What certificate expiry monitoring actually does

A certificate monitor connects to your host over TLS on a schedule, reads the certificate the server presents, and checks the notAfter (expiry) date. When that date is closer than your threshold, it alerts you. Good monitors check the whole chain and catch related problems too:

  • Certificate expiring soon (your main signal).
  • Certificate already expired.
  • Hostname mismatch — the certificate doesn't cover the domain you're hitting.
  • Untrusted chain — a missing intermediate certificate.

How to set it up in StatusCat

  1. Add an SSL check. Create a monitor, choose the SSL/TLS certificate check type, and enter your hostname (e.g. yourdomain.com). Add the port if it's not the standard 443.
  2. Set two thresholds. Warn at 30 days for a calm heads-up and at 7 days as a hard deadline. You'll get a reminder with room to act, then a can't-ignore-it nudge.
  3. Route it somewhere you'll see it. Certificate warnings aren't 3-AM pages — send them to email or a Slack channel your team actually reads.
  4. Repeat for every hostname. Don't forget www vs apex, API subdomains, and any internal services with their own certificates. Each distinct certificate needs its own check.

That's it. From now on you get a friendly reminder weeks ahead of every renewal instead of a customer telling you your site is throwing security warnings.

A quick checklist

  • [ ] Every public hostname has an SSL check (apex, www, and each subdomain).
  • [ ] Thresholds set at 30 and 7 days.
  • [ ] Alerts routed to a channel a human reads.
  • [ ] Internal/appliance certificates covered too.
  • [ ] Domain registration expiry monitored as well — a lapsed domain fails exactly like a lapsed certificate.

StatusCat covers certificate and domain expiry alongside HTTP, TCP, DNS, keyword and heartbeat checks, so one monitor per service watches every layer. It's free for 50 monitors — enough to cover every certificate you own.

Frequently asked questions

How many days before expiry should I be warned?
Warn at 30 days for the first heads-up, and again at 7 days as a hard deadline. Thirty days gives you time to renew calmly; seven days is your 'do it now' alert. StatusCat lets you set both.
Doesn't Let's Encrypt auto-renew? Why monitor it?
Auto-renewal is great until it silently fails — a cron job stops, a DNS challenge breaks, a rate limit hits. Monitoring is the backstop that tells you renewal didn't happen, before the certificate actually expires.
Can I monitor certificates on non-standard ports or internal hosts?
Yes. You can check TLS on any host and port. For internal services that aren't reachable from the public internet, use a heartbeat from a job that checks the certificate itself and pings StatusCat.

Keep reading