← Blog

30/14/7/3 SSL Expiry Thresholds for 2026: Renew at Two Thirds

September 28, 2026

By Nick Phillips, Founder

30/14/7/3 SSL Expiry Thresholds for 2026: Renew at Two Thirds

Set staged alerts at 30, 14, 7, and 3 days, and for automated certificates, trigger renewal at roughly two-thirds of the certificate’s lifetime rather than a fixed day count. Certificate lifetimes are shrinking fast under new industry rules, so automation and a solid inventory matter more than the exact numbers you pick. Start by finding every certificate you actually have. You can’t alert on what you don’t know exists.

TL;DR:

• Certificate lifetimes are rapidly decreasing, with new rules pushing maximum validity down to 47 days by 2029, requiring more frequent renewals.
• Alert thresholds should scale proportionally with the certificate’s lifetime, with renewal triggers set around two-thirds of the total period and multi-stage alerts for manual intervention.
• Automated inventory and continuous monitoring of all certificates are essential to prevent unnoticed expirations and shadow certificates, especially for short-lived certificates.
• Shorter certificate periods make automation critical, as manual processes on annual certificates become unmanageable within a 47-day window.
• Tailoring alerting policies based on certificate type and coverage area helps prevent trust breaks caused by missing intermediate or multi-host certificates.

Table of Contents

• Recommended alert thresholds and what each stage should trigger
• Why certificate lifetimes are shrinking and how that affects alerting
• How to pick an expiry threshold for your team: a practical framework
• Automation and monitoring practices that let you tighten thresholds safely
• Edge cases that will break simple threshold rules and how to handle them
• Copyable staged alerting policy template
• Practitioner notes from Otterwatch and author Nick Phillips
• What actually matters once the lifetimes get short
• Try Otterwatch for your certificate monitoring
• Sources
• FAQ

Recommended alert thresholds and what each stage should trigger

Most teams do fine with four stages: a heads up, a nudge to act, an urgent flag, and a “drop everything” alert. Each one should map to a specific action, not just a louder email.

This ladder assumes a roughly one-year certificate. If your certificates run on shorter cycles, shrink the ladder proportionally instead of keeping fixed day counts:

• For 90-day certificates, notice around 20 days, urgent around 5.
• For 47-day certificates (the eventual floor under the CA/Browser Forum Baseline Requirements), notice around 10 days, critical around 2.
• Keep at least one stage that still allows for human intervention, even on very short lifetimes.

The point isn’t the exact day count. It’s having a defined action attached to each stage so nobody just stares at a warning email and closes it.

Why certificate lifetimes are shrinking and how that affects alerting

The CA/Browser Forum Baseline Requirements lay out a phased schedule that cuts maximum public TLS certificate validity down toward 47 days across 2026 through 2029. That’s a big drop from the 398-day maximum most sites have run on for years.

Shorter lifetimes exist for a reason. A stolen or misissued certificate with a 47-day life does far less damage than one that’s valid for over a year, and the industry is leaning on expiration itself rather than revocation, which browsers have never checked reliably.

For your alerting setup, this changes the math:

• Less time between issuance and expiry means less slack if a renewal job silently fails.
• Manual renewal processes that worked fine on annual certificates become unworkable on 47-day ones.
• Threshold windows need to scale down with the certificate lifetime, not stay fixed at 30/14/7/3 forever.

Automation stops being a nice-to-have and becomes the only way to keep up.

How to pick an expiry threshold for your team: a practical framework

For automated, ACME-based renewals, Let’s Encrypt’s guidance recommends triggering renewal at about two-thirds of the certificate’s total lifetime. That gives you a retry buffer if a validation check fails or a network blip gets in the way.

1. Find your certificate’s total lifetime (90, 45, or the newer 47-day cycle).
2. Multiply by roughly 0.66 to get your renewal trigger point.
3. Add a short manual-action window, typically 7 days, for certificates that need human validation, like OV or EV certs with out-of-band domain checks.
4. Layer your alert stages (30/14/7/3 or the scaled-down equivalent) on top of that trigger so you get warned if the automated renewal doesn’t happen on schedule.

A two-person shop running a handful of ACME-issued certificates behind one load balancer can lean almost entirely on the two-thirds rule and skip most of the manual-window complexity. A larger operation juggling hundreds of certificates across multiple CAs, some requiring manual validation, needs the full staged ladder plus a human review step at the 14-day mark.

Pro Tip: Set your renewal trigger as a percentage of lifetime, not a fixed date, so it survives the next round of TBR changes without a config rewrite.

Automation and monitoring practices that let you tighten thresholds safely

Tight thresholds only work if you trust your data, and that starts with knowing what you have. NIST SP 1800-16 recommends a centralized, automated inventory of every TLS server certificate, paired with continuous monitoring and expiration reporting back to the owners. Without that inventory, you get shadow certificates: ones nobody remembers issuing, sitting on some forgotten internal service until they expire and take something down.

A few practices worth putting in place:

• Run periodic discovery scans across your network and cloud accounts, not just the certificates you know about.
• Prefer ACME or API-based renewal over manual processes wherever the CA supports it.
• Build in retries and a validation fallback method in case your primary DCV path fails.
• Make alerts state-change driven, so a certificate sitting in “warning” for three days doesn’t spam the same message daily.
• Log every renewal and alert action for an audit trail, useful both for debugging and compliance conversations.

Pro Tip: Route your critical-stage alerts through more than one channel (email plus a webhook or Slack ping) so a single dead inbox can’t cause a missed renewal.

Edge cases that will break simple threshold rules and how to handle them

Simple leaf-certificate checks miss a surprising number of real failures. A few things worth checking specifically:

• Chain and intermediates. Your leaf certificate can look fine while an intermediate in the chain is expiring, breaking trust for some clients. Check the whole chain, not just the end-entity cert.
• SAN and wildcard coverage. A wildcard cert doesn’t cover every subdomain pattern, and a multi-SAN cert can quietly drop a name during a renewal. Confirm your monitoring checks each hostname individually.
• CDNs and load balancers. The certificate your monitor sees from the public internet may not be the one actually terminating TLS behind a CDN edge or load balancer pool. Coordinate with whoever manages that layer.
• SNI and multi-tenant hosts. A single IP serving many hostnames via SNI needs per-host probes; a generic port check will only ever validate one certificate on that IP.

Copyable staged alerting policy template

Paste this into your monitoring tool as a starting point and adjust the day counts if you’re running shorter-lived certificates.

1. Configure alerts to fire on state change, not on every check cycle.
2. Run a renewal tabletop drill quarterly: pick a certificate, simulate a failed automated renewal, and confirm the escalation path actually works before you need it for real.

Practitioner notes from Otterwatch and author Nick Phillips

Otterwatch focuses on exactly this problem: friendly, clear notifications about SSL expiry and uptime, without a dashboard full of noise. Nick Phillips has written detailed operational guidance on notification setup for teams building out their own alerting policy.

What actually matters once the lifetimes get short

The conventional advice on this topic spends too much time debating the “right” day count and not enough on whether your renewal automation is trustworthy in the first place. A perfectly tuned 30/14/7/3 ladder is worthless if nobody has verified the ACME client actually completes a renewal without a human watching it.

The real lever is inventory. Most missed renewals aren’t threshold failures, they’re visibility failures: a certificate nobody knew existed, running on a forgotten internal tool, expiring quietly. Get that list complete and accurate first, then worry about tuning day counts.

I’d also push back gently on treating every certificate the same way. A wildcard cert covering your main site deserves tighter alerting and more redundancy in its renewal path than a low-traffic internal dashboard. Spend your attention where an outage actually costs something, and let the framework in this piece scale down for the rest.

— Nick Phillips

Try Otterwatch for your certificate monitoring

Otterwatch keeps this whole problem simple: one calm interface tracking SSL expiry and uptime, with plain email alerts instead of a wall of red. No credit card needed to start.

• Run a quick check right now with the Free SSL Certificate Checker.
• Monitor up to five sites at no cost on the Free plan, or move to Pro at $15 per month for deeper monitoring and more integrations.
• If you’re building out renewal automation alongside your alerts, this guide on API key rotation covers similar patterns for zero-downtime automated credential updates.

Set up your first alert and see the difference between a friendly heads up and a red-alert dashboard.

Sources

Alert thresholds and lifetime schedules in this article draw on the CA/Browser Forum Baseline Requirements, NIST SP 1800-16, and Let’s Encrypt’s lifetime guidance.

• NIST SP 1800-16: TLS Server Certificate Management
• CAB Forum Baseline Requirements (BR-SC095)
• Lets Encrypt post: from 90 to 45-day guidance

FAQ

Is it true that an SSL certificate will expire in 47 days?

Not yet for most certificates, but 47 days is the eventual maximum validity floor under the CA/Browser Forum’s phased schedule running through 2029. Today’s certificates can still run longer depending on when they were issued and under which rules.

What will the validity period of an SSL certificate be in 2026?

Validity periods are in the middle of a staged reduction under the CA/Browser Forum Baseline Requirements, moving from the historical 398-day maximum down toward 47 days by the end of the schedule. The exact maximum during 2026 depends on where your CA sits in that rollout.

How often does an SSL certificate expire?

It depends entirely on the lifetime chosen at issuance, which has historically ranged up to 398 days and is now shrinking under CA/Browser Forum rules. Many providers, including Let’s Encrypt, already issue shorter-lived certificates by default to encourage automated renewal.

Why is SSL now considered completely obsolete?

SSL as a protocol was replaced by TLS years ago, but the term “SSL certificate” is still used informally to mean a TLS server certificate, which is very much active and required for secure connections. The certificates themselves aren’t obsolete, only the older SSL protocol versions they once ran over.

Recommended

• How to Avoid SSL Expiration Warnings: 2026 Guide
• 200 Day Cap Starts March 15, 2026: SSL Renewal Window Tactics for Ops
• SSL Certificate Renewal Explained: 2026 Guide
• SSL Expiry Notification Setup: A Practical Guide