Most certificate expiry outages do not happen because nobody set up an alert. They happen because the alert reached the wrong person, disappeared into a shared inbox that nobody checks, or because the person responsible was unavailable when the alert arrived.
Alert setup is not primarily a technical challenge. It is an organisational one — with technical consequences. Alerting is one component of a broader TLS certificate monitoring programme, and it only works when it sits on top of an accurate inventory of what actually needs renewing.
Why email reminders and calendar alerts fail
Shared inboxes with no clear ownership. The alert goes to it@company.com. Everyone assumes someone else will handle it. Nobody does.
Person-bound reminders. A calendar alert was set up by whoever installed the certificate. That person changes jobs. The reminder still lives in the old calendar. Nobody knows.
First alert arrives too late. A certificate with a 90-day lifetime and a single alert at 14 days is already under pressure. With 47-day certificates (from 2029 onwards), a single alert at 14 days is simply unacceptable — there is no buffer.
No escalation path. The alert fires, the recipient is sick or on holiday. No backup recipient. The certificate expires.
Context-free alerts. The email says "certificate expires in 7 days." Who should do what? Not clear. Action gets delayed.
Recommended alert strategy: three escalation layers
An effective alert strategy has three layers:
Layer 1: Early warning (60 or 30 days)
The first alert is informational — "we need to act within the next month." It goes to the certificate owner and a backup contact. No escalation yet, but it creates visibility early.
For critical systems: use 60 days. For standard systems: 30 days is sufficient.
Layer 2: Action alert (14 days)
By this point the renewal process should already be underway. The alert should include concrete information: the certificate's domain, the issuing CA, and a direct link to the renewal procedure or platform.
Send to the certificate owner and the IT or security lead.
Layer 3: Critical alert (7 days and 1 day)
Escalation alerts. Sent to the certificate owner, the backup contact, and management. The 7-day alert signals a critical situation. The 1-day alert is an emergency escalation.
Consider including a webhook that posts directly to a Slack channel the team actively uses — not just email.
Alert thresholds adapted for 47-day certificates
From 2029, most TLS certificates will have a 47-day lifetime. That fundamentally changes the alert strategy:
| Certificate lifetime | First alert | Action alert | Critical alert |
|---|---|---|---|
| 1 year (365 days) | 60 days | 30 days | 14 and 7 days |
| 90 days | 30 days | 14 days | 7 and 1 day |
| 47 days (from 2029) | 21 days | 10 days | 5 and 1 day |
The alternative to these tightly compressed alert windows is ACME automation: certificates renew automatically, and alerts only fire if automation fails. That is the only scalable solution for 47-day certificates. The guide on manual vs automated certificate management covers when automation is and is not the right answer.
Who should receive which alerts
Alert recipients should be defined per certificate or certificate group — not just globally:
- Primary recipient: The engineer or team responsible for certificate renewal
- Backup recipient: A backup contact who steps in if the primary is unavailable
- Escalation: IT lead or security lead for critical alerts
- Webhook: The team's Slack or Teams channel for broader visibility
Avoid sending every alert to everyone. An inbox receiving 50 daily alerts treats them all as noise.
What an alert should contain
A useful certificate expiry alert should include:
- The certificate's domain(s)
- Exact expiry date and time (UTC)
- Days remaining until expiry
- Issuing CA and certificate type
- Link to renewal or to the platform
- Name of the primary responsible contact
An alert without context delays action. An alert with complete context gives the recipient everything they need to act within five minutes.
How CertControl handles alert setup
The guide above describes what good certificate alerting requires. CertControl implements exactly this:
- Configurable thresholds per certificate. You can set different warning windows for different certificates: 90 days for supplier certificates with long renewal lead times, 21 days for ACME-automated certificates. One global threshold does not fit every situation — CertControl is built to differentiate.
- Named recipients per certificate. Every certificate in CertControl has an assigned owner. Alerts are routed to the specific person or team responsible for renewal — not broadcast to everyone. Backup recipients can be configured, and webhooks deliver alerts to Slack or Teams channels.
- Alert content with full context. CertControl alerts include the domain, the exact expiry date, days remaining, the issuing CA, and a direct link to the certificate detail page in the platform — everything the recipient needs to act immediately.
- ACME automation as an alternative to alert fatigue. For certificates that support automation, CertControl's ACME integration eliminates the renewal process entirely. Alerts fire only if automation fails — not at every scheduled renewal point. This is the only scalable approach for 47-day certificates.
- Alert log as compliance evidence. All alerts are logged with a timestamp and recipient. This log is the documentation that monitoring was active — directly relevant for NIS2 audits and ISO 27001 reviews that require evidence alerts actually fired.
Frequently asked questions
Why do certificate expiry alerts fail even when they are set up?
Alerts usually fail organisationally, not technically: they land in a shared inbox nobody owns, the reminder was tied to a person who changed jobs, there is no backup recipient when the owner is away, or the first alert simply arrives too late to act on.
What is a good certificate expiry alert strategy?
Three escalation layers: an early informational warning (60 or 30 days), an action alert (around 14 days) with concrete renewal details, and critical escalation alerts (7 and 1 day) routed to the owner, backup, and management. Each layer raises both urgency and audience.
What alert thresholds work for 47-day certificates?
With a 47-day lifetime, the windows compress to roughly a first alert at 21 days, an action alert at 10 days, and critical alerts at 5 and 1 day. The more scalable answer is ACME automation, where certificates renew automatically and alerts fire only when automation fails.
Who should receive certificate expiry alerts?
Recipients should be defined per certificate or group: a primary owner responsible for renewal, a backup contact, an IT or security lead for critical escalations, and optionally a Slack or Teams webhook for visibility. Avoid sending every alert to everyone — that turns alerts into noise.
What should a certificate expiry alert contain?
The certificate's domains, the exact expiry date and time in UTC, days remaining, the issuing CA and certificate type, a link to the renewal procedure or platform, and the name of the primary responsible contact. Complete context lets the recipient act within minutes.