How to monitor SSL expiry (and never get caught out)

An expired certificate is one of the few failures that takes a perfectly healthy site offline instantly: the servers are fine, the code is fine, and nobody can get in. It is also entirely predictable, because the expiry date is written inside the certificate itself. This guide shows how to turn that date into an alert you can act on calmly, and how to keep the renewal automation everyone now relies on honest. (New to the topic? The SSL certificate monitoring explainer covers the fundamentals first.)

Why SSL expiry still catches teams out

The moment a certificate's notAfter timestamp passes (and it passes at an exact second, usually an inconvenient one), every browser on earth stops trusting your site. Visitors don't see your page with a subtle warning; they see a full-screen interstitial that actively tells them to leave:

That screen is the gentle version. Browsers at least offer a buried “Advanced” escape hatch. The API clients, mobile apps, payment callbacks and webhook consumers talking to your domain have no such button: TLS validation simply fails, instantly and completely. Integrations error, apps show spinners, and every one of your customers' systems treats you as down. The pattern has form. An expired certificate took Microsoft Teams down for hours in February 2020, Spotify went dark later that year when a wildcard certificate lapsed, and in 2018 expired certificates in Ericsson's core network knocked out mobile data for millions of O2 customers for the best part of a day. None of these were exotic failures. A date passed, and nobody was watching it.

Lifetimes are shrinking: 398 → 47 days

For years the worst case was an annual renewal you could pin to a calendar. That era is ending. In April 2025 the CA/Browser Forum, the body of certificate authorities and browser makers that sets the rules, voted unopposed to shrink the maximum lifetime of public TLS certificates in three steps:

Since 15 March 2026, newly issued public certificates are capped at 200 days, so even the most traditional setup now renews twice a year. By March 2029 the cap is 47 days: a renewal roughly every six weeks, for every certificate you own. The calendar reminder is officially dead as a strategy. At that cadence renewal must be automated, and automated renewal changes the failure mode. The thing that breaks is no longer “we forgot”; it's “the automation stopped working and nothing told us”. More renewals, more quiet ways to miss one.

What an SSL check actually verifies

The important phrase is real handshake. A good SSL check doesn't just look up a date. It negotiates TLS the way a visitor's browser would, which means it also proves the certificate matches the hostname and chains to a trusted root. A forgotten intermediate, a certificate served for the wrong domain, a broken chain after a migration: each fails the handshake, and the check with it, even when the expiry date looks fine.

You can read the same date by hand; this is exactly what the monitor automates:

# Read the expiry date by hand
openssl s_client -connect www.example.com:443 -servername www.example.com \
  </dev/null 2>/dev/null | openssl x509 -noout -enddate
# notAfter=Sep 17 09:41:00 2026 GMT

But a one-off read is the problem, not the solution. The number that matters is a countdown, and a countdown is only useful if something re-checks it every few minutes and speaks up when it crosses a line.

Set up SSL expiry monitoring, step by step

1. 1

   Create an SSL monitor

   In the new-monitor dialog, choose the SSL certificate type and point it at the hostname, for example https://www.example.com. One monitor watches one served certificate; non-standard ports work too (example.com:8443, or a mail host on :465).

2. 2

   Set the warning threshold

   The days-before-expiry threshold decides when the monitor turns amber. The default is 30 days, which suits annually renewed certificates; tune it to your renewal cadence below.

3. 3

   Leave the interval alone

   The default five-minute check is more than enough, because days-to-expiry only moves once a day. The frequent re-check is really there to catch the other failures: a broken chain or a bad deploy shows up within minutes instead of at next week's renewal.

4. 4

   Turn on the early warning, then route it

   An SSL monitor can tell you two things: the early warning as the countdown crosses your threshold, and the hard down alert if the certificate expires or the handshake starts failing. Add an expiry alert rule with a days-before that matches your threshold, attach the channels your team actually reads (Slack, Teams, Telegram, Discord, email or a webhook) and you'll get the calm alert, not just the catastrophic one.

5. 5

   Test it against a deliberately broken host

   Point a temporary SSL monitor at expired.badssl.com, a public test host that intentionally serves an expired certificate. It should go down on its first check and the alert should land in your channel. Delete it once it has. Never trust a monitor you've never seen fire.

6. 6

   Repeat for every hostname that terminates TLS

   Certificates expire per hostname, so inventory them: the apex and www, the API, the status page, the admin panel, mail hosts, the staging box customers somehow found. Each gets its own monitor; the forgotten subdomain is precisely the one that expires.

Choosing your warning thresholds

The threshold turns the expiry date into a runway with three zones: comfortably valid, inside the warning window, and expired. The monitor's job is to make sure you spend the warning window renewing, not discovering:

Where to draw the line depends on how the certificate renews:

• Manually renewed or annually purchased certs: the 30-day default is right. It leaves time for procurement, a change window and a colleague on holiday. Some teams add a second rule at 14 days for escalation.
• Auto-renewed certs (Let's Encrypt and friends): automation typically renews with about 30 days left, so a 30-day threshold fires on the same day the renewal should happen. Set the warning just below the renewal point, at around 21 days, so amber means renewal has been failing for over a week, and keep a sharper rule at 7 days as the backstop.
• The 47-day future: shorter lifetimes need proportionally shorter thresholds; a 30-day warning on a 47-day certificate would be amber for most of its life. Think 10 days, tightening as the caps come down.

The one hard rule: the threshold must be shorter than your renewal cadence. A monitor that's permanently amber trains everyone to ignore it, and an ignored monitor is worse than none.

“But I have auto-renewal” (monitor it anyway)

Auto-renewal is the right answer to shrinking lifetimes, and it is exactly why monitoring matters more, not less. The renewal pipeline has more moving parts than the certificate, and every one of them fails silently:

• The timer died. certbot renew runs from a systemd timer or cron entry that didn't survive the last migration, reimage or “quick tidy-up”.
• The DNS token rotated. DNS-01 challenges authenticate with an API token. Someone rotates it, and every renewal since fails politely in a log nobody reads.
• It renewed but never reloaded. The classic: a fresh certificate sits on disk while nginx or HAProxy keeps serving the old one from memory. The renewal job reports success as the served cert runs out.
• One node renewed, one didn't. Behind a load balancer, some visitors get the stale certificate intermittently. That is the hardest version to spot by hand, and trivial for a monitor that checks repeatedly.
• The host was never automated at all. The mail server, the legacy admin box, the subdomain added after the automation was set up: renewal only covers the hosts someone remembered to include.

The fix is to watch both ends. The renewal job is just a scheduled task, and scheduled tasks deserve a heartbeat check, so you'll hear about it the night the timer stops running. The SSL monitor on the public hostname is the end truth: it verifies the certificate visitors are actually served, whatever the logs claim. Together they cover the job and the result.

Mistakes to avoid

• Watching only the homepage. Every hostname serves its own certificate. The www redirect, the API, mail: any of them can expire independently of the one you watch.
• Alerting only at expiry. A monitor that first speaks up when the certificate lapses has merely renamed the outage. The warning threshold is the feature. Set it, and make sure it notifies.
• A threshold longer than your renewal cadence. Permanent amber is alert fatigue by design, and the channel gets muted just before the alert that mattered.
• Trusting the CDN's padlock. The edge certificate auto-renews; your origin's doesn't necessarily. Check the origin too.
• Confusing certificate expiry with domain expiry. Your domain registration lapses separately, with far worse consequences. That's a different check (a domain monitor watches registration status); run both.
• Never testing the alert. Two minutes against expired.badssl.com is all it takes to know the path from failing handshake to pinged phone actually works.

Frequently asked questions

A certificate carries its own expiry date; nobody should ever be surprised by one. Put a dedicated check on every hostname that terminates TLS, set the threshold below your renewal point, and test the alert once. 247Monitor includes SSL certificate monitoring on every plan (25 monitors free), with checks you can also create through the REST API.