How early should I get warned before an SSL certificate expires?

Early enough to renew on a normal working day rather than during an outage. A first warning at 30 days gives a full renewal cycle of headroom, even for a 90-day Let's Encrypt cert. Tiered alerts at 30, 7 and 1 day remaining escalate the urgency as the deadline closes in, so a low-priority note becomes a phone call only when the cert is genuinely hours from taking the site down.

Why isn't checking that a certificate is valid enough?

A certificate is valid right up to the second it expires, so a valid/invalid check passes every time until it suddenly fails with no warning. The useful number is days remaining. It tells you when the cert expires while you still have room to act, instead of only telling you it has already happened.

Does failover.io need a separate certificate monitor?

No. An HTTPS monitor reads the certificate the server presents on every normal check and extracts its expiry date, so the cert clock is watched alongside the uptime check with nothing extra to configure.

What happens when I renew the certificate?

The next check reads the new certificate's expiry date, the days-remaining number jumps back up, and any open expiry alert clears on its own. No acknowledgement or manual reset is needed.

Guides / Monitoring

Monitoring

How to Monitor SSL Certificate Expiry (Before It Takes the Site Down)

Published June 2026 · ~6 min read

An expired TLS certificate is the cleanest outage there is. Nothing crashes, no disk fills, no traffic spike. The cert reaches its notAfter timestamp, and at that exact second every browser throws NET::ERR_CERT_DATE_INVALID and every API client that validates certs starts refusing the connection. The site worked one minute and was unreachable the next, and the cause is a date you'd known about for months.

Auto-renewal was supposed to end this, and most of the time it does. certbot and the other ACME clients renew Let's Encrypt certs on a timer, and you never think about it. The failures live at the edges: a renewal cron that got switched off during a server migration, a deploy hook that quietly stopped reloading nginx, a DNS-01 challenge that broke when you changed providers, a cert on a box that predates your current automation and isn't in any of it. Renewal runs green right up until the once it doesn't, and the first signal you get is a customer's screenshot.

Why "it's valid" isn't the thing to check

Any monitor can tell you a cert is valid right now. That's close to useless, because a cert stays valid right up to the instant it isn't. The number worth watching is days remaining, and you want it while there's still room to act. A cert with 28 days left is fine; the same cert with 28 hours left is an emergency you should have caught four weeks earlier. A validity check answers a yes/no question. An expiry check answers a "when," and "when" is what lets you renew on a Tuesday afternoon instead of at midnight.

How failover.io checks it

Every time an HTTPS monitor runs its normal check, it also reads the certificate the server hands back and pulls the notAfter date out of it. That produces a days-remaining figure on every check, with no separate cert monitor to set up. The TLS handshake is already happening; reading the expiry off it costs almost nothing.

One alert when the cert finally expires would arrive far too late to help, so the days-remaining figure drives three thresholds instead, each louder than the one before:

Stage	Days remaining	What it means
Warn	30 days	first notice, low urgency, a full renewal cycle of runway
Escalate	7 days	renewal clearly hasn't fired; a human needs to look
Page	1 day	hours from a public outage; wake someone

That shape fits how cert problems actually behave: a long fuse and a hard deadline. Thirty days out, the warning is a note to self. Seven days out, your automation has demonstrably not renewed and somebody should treat it as a real task. One day out, you're past reminders, and the alert climbs the same escalation chain as a hard outage, from Slack to email to SMS to a phone call, until someone acknowledges.

Setting it up

Point a monitor at your https:// URL. The cert check rides along with the uptime check, so there's nothing extra to wire: if the monitor watches https://api.yoursite.com, it's already watching that cert's clock. The thresholds above are sensible defaults for most certs, the 90-day Let's Encrypt ones included, where a 30-day warning is a whole renewal cycle of headroom.

A few situations worth knowing about:

A cert you don't serve over a monitored URL won't be seen. An internal service or a non-web port needs its own monitor aimed at it.
A renewed cert resets the clock by itself. The next check reads the fresh notAfter, days-remaining jumps back up, and any open warning clears without you touching anything.
Wildcard and multi-domain (SAN) certs report a single expiry for the whole certificate, so one monitor per host tracks the shared cert; you don't need a monitor per SAN entry.

The renewal that lies. A successful certbot renew in your logs only proves the cert was reissued, not that the running service picked it up. If the reload hook fails, the new cert sits on disk while the server keeps presenting the old one. Watching the cert the server actually serves catches that gap; watching the renewal job doesn't.

The short version

Certificate expiry is the outage you can watch approach for ninety days and still walk straight into, because auto-renewal holds until the once it doesn't and nothing announces the failure. Track the days-remaining number rather than the valid/invalid flag, and put real escalation behind the final 24 hours. Aim a failover.io monitor at your https endpoint and the cert clock gets read on every check, with a quiet warning at 30 days, a louder one at 7, and a phone call at 1. Renew on a Tuesday, not at midnight.

Stop renewing certs at midnight.

failover.io reads your cert's expiry on every check and escalates as the deadline closes in, all the way to a phone call. Free plan, no credit card.

Start monitoring free →