Monitoring

SSL Expiration Monitoring Guide

SSL outages are uniquely painful: nothing is broken on your origin, the site is running fine, but every browser shows a full-page security warning. The fix is boring and the monitoring is even more boring — which is exactly why it works.

SSL Expiration Monitoring Guide — Prevent Silent Certificate Outages · Why TLS certificates expire silently, how to monitor them across all your domains, and how to build a calm renewal workflow that prevents browser warnings. · /ssl-expiration-monitoring-guide

Why certificate expiry is a monitoring problem, not a setup problem

You can configure perfect auto-renewal today and still have an outage in 90 days. The renewal process depends on a chain of moving parts — DNS, firewall, the ACME client, the host running it. Any one of those drifting silently breaks renewal long before the cert actually expires. Monitoring closes the loop by checking the live certificate, not the renewal config.

What to monitor on every certificate

  • Days until expiry — the single most important field. Alert at 30, 14, and 3 days.
  • Chain validity — an intermediate cert can be expired even when the leaf isn't.
  • Hostname match — confirms the certificate actually covers the hostname users hit.
  • Issuer — a sudden issuer change is a strong signal of a misconfigured renewal or a takeover.

Operational workflow when a cert is about to expire

  1. Receive the 30-day alert. Open the monitor, confirm the cert in question.
  2. Trigger renewal manually if your host supports it; verify it succeeded with a fresh check.
  3. If renewal failed, walk the chain: DNS challenge records, HTTP challenge path, firewall rules.
  4. Once the new cert is live, the monitor's next poll updates the expiry field — no manual confirmation needed.
  5. Log the incident so next quarter's renewal isn't a surprise.

Building a multi-domain SSL monitoring portfolio

One certificate is easy; twenty across customer subdomains, marketing sites, and APIs is where teams lose track. Saving each hostname as its own monitor gives you a single dashboard view of expiry dates, sorted by urgency. The cost of monitoring is trivial; the cost of a single browser-warning outage on a checkout page is not.

Recommended next steps

Diagnostic workflow

  1. 1
    Check the certificate now

    Confirm the current cert, chain, and expiry date.

    Run check
  2. 2
    Read the SSL troubleshooting guide

    Common errors and what they actually mean.

    SSL errors
  3. 3
    Diagnose handshake failures

    When the cert is fine but the handshake fails.

    Handshake guide
  4. 4
    Save the hostname as a monitor

    Get notified at 30, 14, and 3 days before expiry.

    Configure monitor
  5. 5
    Return to operational dashboard

    Review all certs across all monitored hostnames.

    Open dashboard

Frequently asked questions

Why do SSL certificates fail so often?

Most expire because nobody owns them. They renew automatically — until the day they don't, usually because a DNS record changed, a payment lapsed, or an ACME challenge failed silently in the background.

When should I be alerted before expiry?

30, 14, and 3 days out. The 30-day notice gives you a calm window; the 3-day notice catches anything that slipped through the cracks.

Doesn't Let's Encrypt handle this automatically?

It tries. But auto-renewal silently fails when DNS, firewall rules, or HTTP challenges change. Monitoring confirms renewal actually worked instead of trusting that it did.

What about wildcard and SAN certificates?

Same expiry rules apply, but a single failure takes down many hostnames at once. Monitor each customer-facing hostname individually so you see exactly which one is affected.

Is an expired cert just a warning?

No — modern browsers hard-block expired or invalid certs by default. Users see a full-page warning, not a small banner. Conversion drops to near zero immediately.

Continue reading

Educational guide. Diagnostic checks run entirely in your browser.