SSL Certificate Expiry: The Outage Nobody Sees Coming

At 3:17 AM on a Tuesday, your customers start seeing "Your connection is not private" errors in their browsers. Your uptime monitor says the server is up. Your API returns 200. But nobody can actually use your product because your SSL certificate expired 17 minutes ago.

This happens to companies of every size. It happened to Microsoft Teams in 2020. It happened to Spotify. It's happened to more startups than anyone will admit. And it's entirely preventable.

Why Certificates Still Expire in 2026

"But we use Let's Encrypt with auto-renewal!" Great. Here's why certificates still expire even with automation:

• DNS validation fails silently: Your DNS provider changed something, the ACME challenge fails, and the renewal doesn't complete. No error in your application logs.
• Infrastructure drift: Someone rebuilt the server without the certbot cron job. Or the Docker image was updated and the renewal script path changed.
• Load balancer certificates are separate: Your app's certificate auto-renews, but the one on your CDN or load balancer is managed manually and nobody remembers when it expires.
• Wildcard certificates need DNS-01 challenges: These are harder to automate and more likely to break when DNS configurations change.
• Multiple domains, multiple certificates: Your main domain renews fine. The API subdomain's certificate is managed differently and nobody owns it.

What Happens When a Certificate Expires

Unlike a slow API or a degraded database, an expired certificate is a hard failure:

• Browsers block the page entirely. Users see a full-page security warning with no easy bypass
• API clients reject connections. Any client with certificate verification enabled (which should be all of them) gets a TLS handshake error
• Mobile apps crash or hang. Many mobile HTTP libraries don't handle TLS errors gracefully
• Webhooks stop delivering. Third-party services calling your endpoints will get connection refused

The blast radius is 100%. Every single user is affected simultaneously. There's no graceful degradation.

How to Monitor SSL Certificates Properly

1. Check Days Until Expiry

Don't just check if the certificate is valid right now. Check how many days remain until expiry and alert at multiple thresholds:

{
  "type": "ssl",
  "hostname": "api.yourapp.com",
  "port": 443,
  "assertions": [
    { "type": "certificate.daysUntilExpiry", "operator": "gt", "value": 30 },
    { "type": "certificate.issuer", "operator": "contains", "value": "Let's Encrypt" }
  ]
}

2. Validate the Entire Chain

A certificate can be valid but still fail in browsers if the intermediate certificate chain is incomplete. Your monitor should validate the full chain from leaf to root.

3. Monitor All Endpoints

Don't just monitor your main domain. Create SSL checks for every endpoint that uses TLS:

• Main website: yourapp.com
• API: api.yourapp.com
• CDN: cdn.yourapp.com
• Status page: status.yourapp.com
• Internal services: internal.yourapp.com

4. Check After Renewals

After auto-renewal runs, verify that the new certificate is actually being served. A common failure mode is the certificate file updating but the web server not reloading to pick up the new cert.

Setting This Up in upti.my

upti.my's SSL monitoring connects to your domain, inspects the certificate, and continuously tracks days until expiry:

1. Create a new healthcheck and select the SSL/TLS type
2. Enter your hostname and port (443 by default)
3. Configure expiry thresholds (we recommend 30 days as the warning level)
4. Set up alerts (Slack for warnings, PagerDuty for critical)

You'll get a dashboard showing all your certificates, their issuers, expiry dates, and chain status at a glance. When a certificate is approaching expiry, you'll know weeks in advance.

Certificate expiry is one of the most predictable outages in infrastructure. You know exactly when it will happen. The only question is whether you'll catch it before your users do.