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.
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.
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.