An Alerting Policy Is More Than a Threshold
An 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
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 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 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.
Monitoring a Commercial SaaS?
FourSight's free plan includes 10 commercial-safe monitors with multi-region validation — free forever, no card.
Start Monitoring FreeRouting: 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 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
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.