SSL expiry monitoring

The certificate expired on a Saturday. Nobody had to find out.

An SSL monitor connects to your host, reads the certificate, checks the chain and the hostname, and counts the days left. You get a reminder at 30, 14, 7 and 1 days. If it does expire, your status page says so before the tickets do.

Free for one monitor. No card needed.

status.tidepool.ioExpires in 26 days
Issued 12 JulExpires 10 Oct

Reminder sent 30 days out to #ops and 2 email addresses. Next one at 14 days.

  1. status.tidepool.ioLeaf
  2. R11Intermediate
  3. ISRG Root X1Root

Issued by Let's Encrypt. Chain verified against the system trust store, hostname matched, not revoked.

30 · 14 · 7 · 1
Reminder days
443
Default port, any port works
SNI
Per hostname
Chain
Verified to the root

What an SSL monitor checks

Every check opens a TLS connection to your host, with the hostname sent as SNI so the right certificate comes back. It then verifies three things: the chain leads to a trusted root, the certificate matches the hostname, and it has not expired. Any of those failing is a failed check, with the reason spelled out: self-signed, hostname mismatch, issuer missing from the chain, and so on.

It also reads the expiry date and keeps it on the monitor. That is what the reminders run off. Automated renewal fails more often than anyone admits, usually silently, and a 90 day certificate leaves little room. The reminders give you a month of warning and then keep nudging.

Reminders that keep coming until it's renewed

The first reminder goes out at 30 days, then 14, 7 and 1. Each threshold fires once. When the certificate is renewed and the days left jump back up, every threshold re-arms for next time, so the reminders work for the whole life of the host.

  • Reminders go to the team channels you connected: Slack, Discord, Telegram, Teams, email, SMS or a webhook
  • The monitor.ssl_expiring webhook event carries the days left and the expiry date, for your own automation
  • Days left is shown on the monitor list, so the next one to expire is always at the top of your mind
status.tidepool.ioRenewed · 89 days left
  1. Mon 09:00

    30 days left on status.tidepool.io. Reminder sent to #ops and two email addresses.

  2. +16 days

    14 days left. Reminder sent again. Somebody is now looking at the renewal job.

  3. +7 days

    7 days left. Reminder sent.

  4. +2 days

    Certificate renewed. 89 days left. All reminders re-armed for next time.

Every host, not just the website

Mail servers, API gateways, the status page itself, the admin panel on a non-standard port. Enter a hostname or host:port and the monitor uses SNI to fetch that host's certificate specifically.

  • Any port, so SMTP on 587 and custom services are covered
  • Chain problems are reported with the reason, not just “failed”
  • Hourly checks are usually enough; the fastest interval is 30 seconds if you want it
Monitors3 up · 1 expiring
  • tidepool.io
    SSL · every 1 h
    61 days
  • status.tidepool.io
    SSL · every 1 h
    26 days
  • api.tidepool.io
    SSL · every 1 h
    74 days
  • mail.tidepool.io:587
    SSL · every 24 h
    312 days

Setting one up

01

Enter the host

A hostname, an https:// URL, or host:port for anything not on 443.

02

Pick an interval

Once an hour catches an expiring certificate with days to spare. Daily is fine for long-lived ones.

03

Choose who is reminded

Team alerts go to your connected channels. Link a component if customers should see an expired certificate as an outage.

The other checks

SSL monitoring questions

Never renew a certificate in a panic again.

One monitor and a status page, free. No card needed.

Add an SSL monitor