SSL Monitoring

SSL Expiry Alerts: Setting Up 30/14/7 Day Warning Windows

Set up SSL expiry alerts with 30, 14, and 7-day warning windows. Configure escalating notification systems to ensure certificates are never forgotten.

AzMonitor TeamFebruary 28, 20256 min read · 882 wordsUpdated January 20, 2026
SSL expirySSL alertscertificate expiryHTTPS monitoring

The difference between a planned certificate renewal and an emergency response is advance warning. A 30-day alert gives you time to schedule renewal during normal business hours. A 3-day alert means someone is scrambling to renew at 11 PM on a Friday. Setting up the right alert windows — and routing them to the right people — is the core of effective SSL certificate management.

The Multi-Window Alert Strategy

A single "certificate expires soon" alert isn't enough. By the time that single alert fires and gets acted on, there might not be enough runway for complications. A multi-window approach ensures multiple opportunities to catch and act on expiring certificates:

60-day window: First notification. Acknowledge that a certificate needs renewal in the next two months. Add to the team's maintenance schedule.

30-day window: Renewal should begin now. This gives 30 days for complications — DNS propagation issues, CA validation delays, ordering wildcard certs through a commercial CA.

14-day window: Escalation if not yet renewed. Something is blocking renewal. Elevate priority, identify the blocker, get help if needed.

7-day window: Emergency escalation. Whatever is blocking renewal must be resolved today. Wake up the right people.

2-day window: All-hands. If a certificate reaches 2 days until expiry without renewal, treat it as a production incident.

Expired: Full incident response. Users are blocked from your site.

Configuring Alert Routing by Window

Different windows should reach different people through different channels:

# AzMonitor SSL alert configuration
ssl_alert_rules:
  - name: "60-day warning"
    days_remaining: 60
    channels:
      - type: email
        to: ops-team@company.com

  - name: "30-day warning"
    days_remaining: 30
    channels:
      - type: email
        to: [ops-team@company.com, engineering-manager@company.com]
      - type: slack
        channel: "#ops-alerts"

  - name: "14-day warning"
    days_remaining: 14
    channels:
      - type: email
        to: [ops-team@company.com, cto@company.com]
      - type: slack
        channel: "#critical-alerts"
      - type: sms
        to: [on-call-engineer]

  - name: "7-day critical"
    days_remaining: 7
    channels:
      - type: pagerduty
        service: ssl-certificates
      - type: sms
        to: [on-call-engineer, engineering-manager]

Certificate Inventory Management

Before configuring alerts, you need to know what certificates you have. Many organizations discover certificates they didn't know existed when one expires unexpectedly.

Certificate discovery methods:

1. DNS enumeration: Enumerate subdomains and check each for certificates.

2. Certificate Transparency logs: All publicly-issued certificates appear in CT logs. Tools like cert.sh or crt.sh can enumerate all certificates issued for your domains:

https://crt.sh/?q=%.yoursite.com

3. Network scanning: Tools like ssllabs-scan or testssl.sh can scan your IP ranges for certificate-serving services.

4. Web server inventory: Query your server inventory for all HTTPS-enabled services.

Add everything to monitoring:

yoursite.com        - expires 2025-06-15
www.yoursite.com    - expires 2025-06-15 (same cert, wildcard)
api.yoursite.com    - expires 2025-07-22
admin.yoursite.com  - expires 2025-09-30
partner.yoursite.com - expires 2024-11-01  ← Alert!

Handling Let's Encrypt Certificates

Let's Encrypt certificates expire every 90 days, making multi-window alerting especially important. 90 days sounds like plenty of time, but the window for catching renewal failures is narrow.

Recommended monitoring for Let's Encrypt:

# More aggressive alert windows for short-lived certs
letsencrypt_ssl_alerts:
  - days_remaining: 30  # 33% of cert lifetime
    severity: warning
  - days_remaining: 14  # Two weeks before expiry
    severity: critical
  - days_remaining: 7   # Emergency
    severity: emergency

Auto-renewal monitoring: In addition to expiry alerts, monitor whether your Let's Encrypt auto-renewal is actually running:

# Check when certbot last renewed
certbot certificates

# Output includes:
# Expiry Date: 2025-06-15 10:23:45+00:00 (VALID: 45 days)

Set up a monitoring script that alerts if the certificate's remaining validity drops below what auto-renewal should prevent:

#!/usr/bin/env python3
"""Monitor Let's Encrypt renewal health"""
import subprocess
import sys

def check_certbot_status():
    result = subprocess.run(['certbot', 'certificates'], 
                           capture_output=True, text=True)
    
    # Parse output for certificates near expiry
    # Alert if any cert has < 30 days remaining AND auto-renewal should have caught it
    # (Let's Encrypt renews at 60 days, so < 30 days means renewal failed)
    
    if "VALID: 0 days" in result.stdout or "EXPIRED" in result.stdout:
        return False, "Certificate is expired!"
    
    return True, "All certificates healthy"

SSL Alerts During Certificate Migration

When migrating to a new CA or certificate type (e.g., single-domain to wildcard, old CA to Let's Encrypt), temporarily pause SSL expiry alerts for the old certificate to avoid false urgency while renewal is in progress.

# AzMonitor API: Pause SSL alerts during migration
curl -X POST https://api.azmonitor.com/v1/monitors/ssl-yoursite/pause \
  -H "Authorization: Bearer $API_KEY" \
  -d '{"duration_hours": 24, "reason": "Certificate migration in progress"}'

Building a Certificate Runbook

Every SSL alert tier should have an associated runbook:

30-day alert runbook:

  1. Log into the server/hosting environment
  2. Check if auto-renewal is configured (certbot certonly --dry-run -d domain.com)
  3. Trigger manual renewal if auto-renewal isn't working
  4. Verify new certificate is being served (openssl s_client -connect domain.com:443)
  5. Update expiry date in certificate inventory spreadsheet

7-day emergency runbook:

  1. Identify the blocker preventing renewal (firewall, DNS, rate limit)
  2. Escalate to engineering manager immediately
  3. Consider emergency workarounds (temporary certificate from different CA, CDN SSL termination)
  4. Update status page if renewal might not complete before expiry
  5. Post-mortem once resolved: why did we reach 7 days?

AzMonitor's SSL monitoring fires alerts at configurable windows for every HTTPS endpoint. Set up SSL expiry monitoring and build your certificate management system on top of reliable automated tracking.

Related: SSL certificate monitoring overview for the broader context of what SSL monitoring covers beyond just expiry dates.

Tags:SSL expirySSL alertscertificate expiryHTTPS monitoring
Back to blog
A
AzMonitor Team
The AzMonitor team writes guides based on experience monitoring millions of endpoints daily across 10,000+ customer environments. Our expertise covers uptime monitoring, SRE practices, and reliability engineering.
Try AzMonitor free

3 monitors free forever · No credit card needed · Set up in 2 minutes

Start monitoring free →