SSL certificate expiry monitoring: why shorter certificates make it mandatory

Published 9 September 2026 · Updated 11 September 2026 · Merik team · 5 min read

Public TLS certificates issued since 15 March 2026 are limited to 200 days' validity; the limit falls to 100 days in March 2027 and 47 days in March 2029, under the CA/Browser Forum ballot adopted in April 2025. That makes automated renewal mandatory in practice — and automated renewal fails silently more often than people expect: a DNS change breaks validation, a rate limit is hit, an ACME client is left on a decommissioned server, a wildcard's DNS token stops working. The user then sees a full-page browser warning, and the site is effectively down while every uptime check reports success on the redirect. Expiry monitoring — a daily check of days remaining on every certificate you own or manage, alerting at 14, 7 and 3 days — is the control that closes the gap.

The shortening timeline

Before March 2026	398 days maximum (since 2020)
From 15 March 2026	200 days maximum validity; domain validation reuse cut to 200 days
From 15 March 2027	100 days maximum; validation reuse 100 days
From 15 March 2029	47 days maximum; validation reuse 10 days

The stated reasons are sound — revocation does not work well at internet scale, and a short-lived certificate limits how long a compromised key is useful — but the operational effect for a small team or an agency with forty client sites is that certificate renewal has moved from "annual task" to "continuous process", and continuous processes need monitoring. Facts checked 11 September 2026.

What an expired certificate looks like to a user

A full-page browser interstitial — "Your connection is not private", a red warning, a button most people will not click. For an e-commerce site it is a 100% conversion drop. For a SaaS login it is a support queue. For an API it is every client's TLS handshake failing with an error that looks, from their side, like your service refusing connections. Meanwhile a basic uptime check that follows the HTTP redirect and does not validate the chain may keep reporting "up" — one more case of the application being up while users see errors.

Why automated renewal fails silently

• DNS changed. The domain moved providers, the CNAME for validation was not recreated, HTTP-01 validation now hits a different server.
• The ACME client lives on a server that is gone. The site moved to a CDN or a new host; the cron job that renewed it is still running on the old box, or nowhere.
• Rate limits. Too many renewals for one registered domain in a week — common when a script loops on a failure.
• Wildcard DNS-01 token broken. The API key the client uses to write the validation record was rotated.
• The renewal worked; the deploy did not. A new certificate was issued but the load balancer, CDN or container still serves the old one.
• Nobody owns it. The person who set it up left. Shorter lifetimes shrink the window in which that goes unnoticed from a year to weeks.

In every case the renewal log says something went wrong, and nobody reads renewal logs. Logs are records, not lookouts.

What to monitor, and when to alert

1. Days remaining, checked daily from the outside on every hostname — the served certificate, not the one on disk. Alert at 14, 7 and 3 days.
2. Chain validity — an intermediate that expired or was not sent is as fatal as the leaf.
3. Hostname match — a certificate that renewed for the apex but not the www, or vice versa.
4. Renewal success, inferred: if days remaining should have jumped and did not, the renewal failed. With 47-day certificates, "renewal did not happen at day 17" is the alert that matters.
5. Every hostname you own or manage — including client sites, staging, and the API subdomain nobody visits in a browser.

Alerts go to a named owner, once, with the hostname and the expiry date. Fourteen days is enough to fix DNS; three days is the last call. One of the ten issues monitoring should detect without a human.

The inventory problem

The hard part is not checking a certificate; it is knowing which certificates exist. Agencies and small teams accumulate hostnames — client sites, redirect domains, staging, APIs, the marketing site's old subdomain — and each one has a certificate on a schedule. Keep the list where the monitoring is: every asset registered, each with an owner and the renewal method. When a site is registered for uptime monitoring, its certificate is monitored with it, and the inventory maintains itself. Per-client monitoring for agencies covers the structure.

Quick reference

Maximum validity	200 days (since 15 Mar 2026) → 100 days (Mar 2027) → 47 days (Mar 2029)
User impact of expiry	Full-page browser warning; site effectively down
Why renewal fails	DNS change, dead ACME client, rate limits, rotated API keys, issued-but-not-deployed, no owner
Check	Daily, outside-in, on the served certificate, every hostname
Alert thresholds	14, 7 and 3 days remaining; one alert to a named owner
Also check	Chain validity, hostname match, that renewal actually happened

Frequently asked questions

How Merik handles it

Every website, web app or API registered in Merik's Digital Operations module gets a daily SSL certificate expiry check alongside its availability and response-time checks, from the outside, on the certificate actually being served. Days remaining are visible per asset; an approaching expiry raises a warning to the asset's owner, once, by email or Slack. Because assets are registered per client, the inventory problem solves itself — the client site you registered for uptime is the client site whose certificate is being watched.

Certificate status is a standing section of the monthly per-client SLA report, so a renewal that went smoothly is visible to the client as a delivered service rather than an absence of complaints. See the Digital Operations module.

Create your workspace →

Or talk to us about your team →