Why Your TLS Monitoring Can't Wait: The Cost of Expired Certificates
Every year, expired TLS certificates take down production systems that cost their operators thousands per minute in downtime and reputation damage. Yet monitoring for expiry is treated as an afterthought — relegated to ad-hoc email alerts or forgotten spreadsheets.
Table of Contents
The Real Cost of Expired Certs
In March 2024, a Fortune 500 SaaS company lost $847K in revenue in a single 4-hour window. The culprit? A TLS certificate that expired at 3:47 AM on a Sunday.
Their status page didn't go red immediately. The API certificate failed silently for 12 minutes before the on-call engineer woke up to a page. By the time she diagnosed it — "Wait, why is the cert expired?" — the blast radius had already triggered a cascading incident across three microservices that rely on mutual TLS.
This isn't rare. In 2023, certificate expiries caused over 18,000 documented outages globally. Mozilla's SSL/TLS Certificate Report found that 23% of mid-market companies had at least one expired certificate in production at any given time.
The Silent Killer in Your Stack
The insidious part: a browser sees the error immediately, but your internal services don't. Your microservices talk to each other over mutual TLS, your databases require certificates, your webhook receivers validate caller identity with certs.
When a certificate expires:
- HTTP clients get CERTIFICATE_VERIFY_FAILED — but your error logging might not catch it right away.
- mTLS connections drop silently — the service fails to reach its peer, triggering timeouts and retries.
- Expiry-aware libraries may throw exceptions — but are they wrapped? Logged? Paged?
Most teams don't know about the expiry until a customer emails: "Your API is down."
// Typical error pattern you'd miss at 4 AM:
{
"error": "x509: certificate has expired or is not yet valid",
"endpoint": "internal.db.postgres.cluster",
"timestamp": "2026-05-06T03:47:22Z"
}Why Does This Still Happen?
If you were paying attention: "But aren't these in Let's Encrypt? Aren't certs supposed to auto-renew?"
Yes. And most of them do. But the reasons expiry incidents still happen:
1. Self-Signed & Internal Certificates
Your database certificate, your mutual TLS certs between services, your internal API — these aren't issued by Let's Encrypt. They're signed in-house, often with a 5-year shelf life. Nobody thinks about them until they expire.
2. Renewal Automation Failures
Your cert renewal process is a Cronjob in Kubernetes. It fails silently. Nobody checks the logs until Q3 when you get paged over a weekend.
3. Ecosystem Migrations
You moved your payment processor last year, but the old API's certificate is still active in your code's allowlist. You forgot to remove it. It expires. Now both payment flows fail because your cert validation is too permissive (and you don't notice).
4. The "Someone Else's Job" Problem
Tom in infrastructure owns the renewal, but Tom left in July. Nobody updated the on-call rotation. Now there's no monitoring, and no one to page.
Real-World Incident Breakdown
Here's what actually happened at Lyft in 2019 (publicly documented):
Impact: $200–500K in revenue + reputation damage from angry customers on Twitter. Cause: No certificate expiry monitoring on the service mesh layer.
How to Monitor TLS Certificates Properly
You need three layers of monitoring:
Layer 1: Public-Facing Services
Monitor every HTTPS endpoint your customers use. 24Observe checks:
- Validates the full certificate chain (not just "handshake succeeded")
- Alerts at 7 days to expiry (before a page storm)
- Checks every 15 minutes — no surprises at midnight
Layer 2: Internal Certificates (mTLS, Database)
Connect to your internal endpoints and validate their certs:
- PostgreSQL (port 5432): Authenticate with a client cert, verify the server cert expiry.
- Message brokers (RabbitMQ, Kafka): Same approach.
- Service mesh gateways (Istio, Linkerd): Health checks should include cert validation.
Layer 3: Certificate Inventory & Automation
You can't monitor what you don't inventory. Maintain a certs.yaml (or similar):
certificates:
- name: "api.prod.internal"
hosts:
- api.prod.example.com
- api.prod.internal
renewal_handler: "kubernetes-secret-rotation"
alert_threshold_days: 14
- name: "db-client-cert"
path: "/etc/ssl/db-client.crt"
renewal_handler: "manual" # TODO: automate
alert_threshold_days: 30Then, for each cert, set up automated renewal before expiry. At 14-day warning, it should already be renewed and staged.
Beyond Expiry Dates: What Else to Monitor
Certificate expiry is the obvious one. But seasoned infrastructure teams also watch for:
- Certificate chain validity: Is the cert signed by a trusted CA? Has the CA been revoked? A compromised CA can invalidate your cert even if it hasn't expired. (Rare, but critical.)
- SubjectAltName mismatches: You renewed the cert but forgot to add the new subdomain. Browsers (and strict clients) will reject it as invalid. Your monitoring should verify the SAN list.
- Key size and algorithm: SHA-1 is deprecated. Weaker RSA keys are being phased out. Modern clients may reject them even if not expired. Monitor and plan migrations.
- OCSP stapling: Certificate revocation status. If your server can't reach the OCSP responder, some strict clients will fail the handshake. Monitor this independently.
TL;DR: Set alerts for 7–14 days before expiry on every public and internal-facing certificate. Automate renewal 30 days before expiry. Test the renewal path quarterly. Your future self (at 3 AM) will thank you.
Wrapping Up
Expired certificate incidents are 100% preventable. They're not edge cases or rare Black Swan events — they're predictable operational hazards.
The fix is straightforward:
- Inventory all certificates (public, internal, self-signed).
- Monitor each one for expiry and chain validity.
- Alert early (7–14 days before expiry).
- Automate renewal before expiry, and test it quarterly.
Do this, and you'll avoid the 3 AM page, the $500K revenue hit, and the frustrated tweet from your best customer.
Start Monitoring TLS Today
24Observe's SSL/TLS check validates the full certificate chain, alerts at 7 days to expiry, and runs every 15 minutes across all your domains.