--- title: "Designing an SSL Expiry Alerting Policy That Actually Gets Acted On | FourSight" description: "30/14/7-day ladders, who gets paged at each rung, and how shrinking certificate lifetimes change the math on alert thresholds." lang: en json-ld: | [ { "@context": "https://schema.org", "@type": "Article", "headline": "Designing an SSL Expiry Alerting Policy That Actually Gets Acted On", "description": "30/14/7-day ladders, who gets paged at each rung, and how shrinking certificate lifetimes change the math on alert thresholds.", "author": { "@type": "Organization", "name": "FourSight" }, "publisher": { "@type": "Organization", "name": "FourSight" }, "url": "https://foursight.cloud/guides/ssl-expiry-alerting-policy", "mainEntityOfPage": "https://foursight.cloud/guides/ssl-expiry-alerting-policy", "datePublished": "2026-07-14", "dateModified": "2026-07-14", "wordCount": 1600 }, { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://foursight.cloud" }, { "@type": "ListItem", "position": 2, "name": "Guides", "item": "https://foursight.cloud/guides" }, { "@type": "ListItem", "position": 3, "name": "Designing an SSL Expiry Alerting Policy That Actually Gets Acted On", "item": "https://foursight.cloud/guides/ssl-expiry-alerting-policy" } ] }, { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "What are the best SSL expiry alert thresholds?", "acceptedAnswer": { "@type": "Answer", "text": "30, 14, and 7 days before expiry is the standard ladder and a sound default for 90-day-or-longer certificates. The refinement that matters more than the exact numbers: make sure the first threshold sits at or just below your automation's renewal trigger, so any alert means a renewal has genuinely been missed, and compress the whole ladder proportionally for shorter-lived certificates." } }, { "@type": "Question", "name": "Should SSL expiry alerts page the on-call engineer?", "acceptedAnswer": { "@type": "Answer", "text": "Only the final rung. A 30-day warning is a ticket; a 14-day warning is an escalated ticket; a 7-day warning — a certificate that's survived two earlier alerts unrenewed — is legitimately page-worthy. Configuration failures (hostname mismatch, broken chain, failed handshake) are different: those are live outages and should page immediately at any hour." } }, { "@type": "Question", "name": "Why did my expiry alert fire and then resolve itself?", "acceptedAnswer": { "@type": "Answer", "text": "Your alert threshold probably matches your automation's renewal trigger. If certbot renews certificates at 30 days remaining and your alert also fires at 30 days, the cert can cross the line hours before the next renewal run replaces it. Either set the threshold a few days below the renewal trigger, or treat the brief alert as a confirmation the automation is alive." } }, { "@type": "Question", "name": "How do shrinking certificate lifetimes affect alerting policy?", "acceptedAnswer": { "@type": "Answer", "text": "Fixed-day ladders stop working as maximum lifetimes fall from 200 days (since March 2026) toward roughly 47 days by 2029. Think in fractions of your renewal safety margin instead: alert when a third of the margin between expected renewal and expiry is gone, escalate at two-thirds, page in the final days. The fractions survive every lifetime change; fixed numbers don't." } }, { "@type": "Question", "name": "Who should receive certificate expiry alerts?", "acceptedAnswer": { "@type": "Answer", "text": "A role, never a person: shared channels, team inboxes, and on-call rotations. A striking share of expiry incidents trace back to warnings sent to an individual who changed teams or left — the same fragility that led Let's Encrypt to drop expiry emails in 2025 in favor of telling users to monitor. Every certificate should also have a named owner recorded in your inventory, so escalation has a destination." } } ] } ] --- [FourSight ](/) [Features](/#features)[Pricing](/pricing)[Guides](/guides)[Glossary](/glossary)[FAQ](/faq) [Login](/auth)[Start free](/auth?signup=true) [Start free](/auth?signup=true) [All Guides](/guides) Reliability & Infrastructure # Designing an SSL Expiry Alerting Policy That Actually Gets Acted On 30/14/7-day ladders, who gets paged at each rung, and how shrinking certificate lifetimes change the math on alert thresholds. 8 min read Guide Published Jul 14, 2026 ## An Alerting Policy Is More Than a Threshold An [SSL](/glossary/ssl-tls "Glossary: SSL") expiry alerting policy answers four questions: how many days before expiry each alert fires, who receives each one, through which channel, and what happens if nobody acts. Most teams answer only the first question, accept a tool's default, and route everything to a Slack channel where a 30-day warning has the same visual weight as a lunch order. The result is the most preventable outage in production happening to teams that technically had monitoring — the alert fired, scrolled away, and the certificate expired 30 days later on schedule. This guide covers the design of a ladder that escalates in urgency as the deadline approaches, the routing that puts each rung in front of someone accountable, and how the industry's shrinking certificate lifetimes are changing the arithmetic underneath all of it. Related Reading - [→ Feature: SSL certificate monitoring](/features/ssl-monitoring) ## Why 30/14/7 Is the Standard Ladder FourSight's default thresholds — 30, 14, and 7 days before expiry — encode an assumption worth making explicit: each rung means something different has gone wrong, so each rung deserves a different response. ### 30 Days: Your Automation Has Already Failed For a 90-day [Let's Encrypt](/glossary/lets-encrypt "Glossary: Let's Encrypt") certificate with certbot defaults, renewal happens when 30 days remain — so a certificate that's still unrenewed below the 30-day line has already missed at least one scheduled renewal attempt. The 30-day alert isn't 'expiry is distant'; it's 'the machine that was supposed to handle this has stopped.' The correct response is a calm, scheduled investigation: check the timer, run a dry-run, read the ACME client logs. There's ample time, which is exactly why this rung should create a ticket, not a page. ### 14 Days: The Calm Window Is Closing Two weeks out with no renewal means either nobody acted on the 30-day alert or the fix didn't work. This rung exists to defeat the 'someone else saw it' failure mode: it should escalate past the original recipient — to the service owner plus their lead, or a broader channel — and it should reference the earlier alert. If your renewal requires coordinating with an external party (a client's [DNS](/glossary/dns "Glossary: DNS") admin, a vendor), 14 days is the last comfortable moment to start that conversation. ### 7 Days: Treat It as an Incident One week out, the question changes from 'why didn't automation work?' to 'a human must renew this certificate manually, now.' This rung should page whoever is on call, carry incident-level urgency, and trigger the manual-renewal runbook. Seven days sounds generous until you subtract a weekend, a discovery that the DNS credentials are in a departed employee's password manager, and a CA rate limit — the padding exists because renewals under pressure hit exactly those snags. ## Tuning the Ladder to Your Renewal Window The one refinement worth making to any default ladder: know the relationship between your first threshold and your automation's renewal trigger. If certbot renews at 30 days remaining and your first alert also fires at 30 days, a certificate can dip briefly below the line in the hours between crossing it and the next timer run — producing an alert that resolves itself. Two clean solutions: set the first threshold just below the renewal trigger (25 days with a 30-day renewal trigger) so any alert means renewal is genuinely overdue, or keep 30 and treat a same-day auto-resolve as a free confirmation your automation works. What matters is intentionality — a threshold chosen relative to your renewal window turns every alert into signal. For certificates renewed by a hosting provider on an unknown schedule, observe when renewal actually happens for one cycle, then set the first rung a few days after that point. **💡** FourSight's warn thresholds are configurable per monitor, so a 90-day Let's Encrypt estate, a 200-day commercial cert, and a client's manually renewed certificate can each carry a ladder matched to their actual renewal rhythm. ### Monitoring a Commercial SaaS? FourSight's free plan includes 10 commercial-safe monitors with multi-region validation — free forever, no card. [Start Monitoring Free](/auth?signup=true) ## Routing: Every Rung Needs an Owner Thresholds without routing are how certificates expire with green dashboards. Two principles do most of the work. First, alerts must survive personnel changes: route to shared channels, team inboxes, and on-call rotations — never to an individual's email, which is how the industry got a decade of expiry incidents traceable to a departed employee's inbox (and part of why Let's Encrypt retired reminder emails entirely in 2025). Second, urgency must be legible in the channel: the 30-day rung belongs in a ticket queue or working channel, the 7-day rung belongs in the pager. A reasonable mapping for a small team, using escalation policies where available: Rung Channel Recipient Expected action 30 days Ticket + Slack Service owner Diagnose renewal automation this week 14 days Slack + email Owner + team lead Escalated fix; loop in external parties 7 days Page (on-call) On-call engineer Manual renewal via runbook, today Handshake/chain/mismatch failure Page (on-call) On-call engineer Immediate incident — users are affected now ## Not Everything Is a Countdown: The Immediate-Page Class Expiry is the only certificate problem that announces itself weeks ahead; the rest are already outages when detected. A hostname mismatch — a valid certificate served for the wrong domain after a [CDN](/glossary/cdn "Glossary: CDN") fallback or a load balancer change — is breaking browsers the moment it appears. A chain that stops validating, a handshake that stops completing, a certificate replaced by an unexpected issuer: all of these belong in the immediate-page class alongside a failed HTTP check, not in the countdown ladder. Design your policy with both classes explicitly: countdown alerts escalate over weeks; configuration alerts page in minutes. Conflating them in one channel teaches responders that 'SSL alert' sometimes means 'in a month' — a lesson they'll remember at the wrong moment. Related Reading - [→ Certificate chain vs leaf expiry: what actually expires](/guides/certificate-chain-vs-leaf-expiry) ## Shrinking Lifetimes Are Compressing Every Ladder The CA/Browser Forum schedule adopted in 2025 caps newly issued public certificates at roughly 200 days from March 2026, about 100 days from 2027, and around 47 days by 2029. A 30/14/7 ladder makes no sense against a 47-day certificate — the first alert would fire before the certificate was two weeks old. The durable way to think about thresholds is as fractions of the gap between renewal and expiry: first alert when roughly a third of that safety margin has been consumed, escalation at two-thirds, page when only days remain. For a 90-day cert renewed at day 60, that reproduces approximately 20/10/5. For the coming 47-day world with renewal around day 30, it implies something like 12/6/3 — tighter numbers, same logic. Teams that internalize the fraction rather than the fixed numbers will re-tune painlessly as lifetimes shrink; teams that hard-coded '30 days' into runbooks will get a strange month. [Configure per-monitor SSL alert thresholds →](/features/ssl-monitoring) Related Reading - [→ How SSL certificates expire silently: the failure modes](/guides/how-ssl-certificates-expire-silently) - [→ SSL monitoring for agencies & multi-client teams](/guides/ssl-monitoring-for-agencies) - [→ Alerting without alert fatigue](/guides/alerting-without-alert-fatigue) ## Frequently Asked Questions ### What are the best SSL expiry alert thresholds? ### Should SSL expiry alerts page the on-call engineer? ### Why did my expiry alert fire and then resolve itself? ### How do shrinking certificate lifetimes affect alerting policy? ### Who should receive certificate expiry alerts? #### Related Guides [What Is Uptime Monitoring? The Complete Guide 12 min ](/guides/what-is-uptime-monitoring)[Multi-Region Monitoring Explained 8 min ](/guides/multi-region-monitoring-explained)[SSL Certificate Expiry Monitoring 10 min ](/guides/ssl-certificate-expiry-monitoring)[How SSL Certificates Expire Silently: The Failure Modes 8 min ](/guides/how-ssl-certificates-expire-silently) #### Compare FourSight [vs UptimeRobot →](/compare/uptimerobot-alternative)[vs StatusCake →](/compare/statuscake-alternative)[vs Pingdom →](/compare/pingdom-alternative) 10 free commercial-safe monitors [View Pricing](/pricing) ## Protect Your SaaS Revenue Start monitoring in under 60 seconds. [Start Monitoring Free](/auth?signup=true)[View Pricing](/pricing) FourSight © 2026 [TetraCore](https://tetracorehq.com/). All rights reserved. FourSight is a TetraCore product — Bowling Green, Ohio. Product [Pricing](/pricing)[Guides](/guides)[Glossary](/glossary)[FAQ](/faq)[About](/about)[For Agencies](/solutions/agencies)[For Startups](/solutions/startups)[Privacy](/privacy)[Terms](/terms) Features [Cron Job & Heartbeat Monitoring](/features/cron-job-monitoring)[SSL Certificate Monitoring](/features/ssl-monitoring)[Status Pages](/features/status-pages)[Domain Expiry Monitoring](/features/domain-expiry-monitoring)[DNS Monitoring](/features/dns-monitoring)[Port Monitoring](/features/port-monitoring) Compare [All comparisons](/compare)[vs UptimeRobot](/compare/uptimerobot-alternative)[vs StatusCake](/compare/statuscake-alternative)[vs Freshping](/compare/freshping-alternative)[vs Pingdom](/compare/pingdom-alternative)[vs Pulsetic](/compare/pulsetic-alternative)[vs Better Stack](/compare/better-stack-alternative)[vs Uptime Kuma](/compare/uptime-kuma-alternative)[vs Cronitor](/compare/cronitor-alternative)[vs Healthchecks.io](/compare/healthchecks-alternative)[vs Hyperping](/compare/hyperping-alternative) Pricing Guides [UptimeRobot Pricing](/compare/uptimerobot-pricing)[StatusCake Pricing](/compare/statuscake-pricing)[Pingdom Pricing](/compare/pingdom-pricing)[Better Stack Pricing](/compare/better-stack-pricing)[Uptime Kuma Pricing](/compare/uptime-kuma-pricing)[Cronitor Pricing](/compare/cronitor-pricing)[Healthchecks.io Pricing](/compare/healthchecks-pricing)[Hyperping Pricing](/compare/hyperping-pricing)[Pulsetic Pricing](/compare/pulsetic-pricing)