Quick Answer: Monitor SSL certificate expiration by connecting to each hostname over TLS, reading the certificate's notAfter date, and alerting when days remaining cross your thresholds. Set warnings at 30, 14, and 7 days before expiry. Uptime checks that only verify HTTPS works today will not warn you that a cert expires next week.
Why do SSL certificates expire without anyone noticing?
Expired certificates are one of the most avoidable outages in production. The site was working fine yesterday. Today every visitor sees a browser warning, your API clients throw TLS errors, and your on-call engineer is digging through DNS records trying to figure out which load balancer serves the bad cert.
The pattern is predictable. Someone provisioned the certificate months ago. Auto-renewal was supposed to handle it, but the renewal job failed silently, the approval email went to a former employee, or a staging cert on a forgotten subdomain was never added to the inventory. Nobody was watching the calendar.
Uptime monitoring does not solve this by default. A check that confirms your homepage returns HTTP 200 over HTTPS only proves the connection works right now. It does not parse the certificate chain or track how many days remain. Your monitor can report "up" on Friday and your cert can expire on Saturday night with zero warning.
Certificate expiry is a different question than availability. Availability asks whether the server responds. Expiry monitoring asks what certificate the server is presenting and when it stops being valid. You need both.
How do you check when an SSL certificate expires?
You have three practical options: manual inspection, a script you maintain, or an automated monitor built for TLS checks.
Manual check with OpenSSL works for one-off debugging. Run this against any public hostname:
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -enddate
The output shows the notAfter date. Useful when you are troubleshooting a single domain. Terrible as a long-term strategy across dozens of subdomains, internal load balancers, and environments that rotate on different schedules.
A cron job or script scales better. Poll each hostname daily, calculate days remaining, and send a Slack or email alert when you cross a threshold. Teams often start here. The downside is maintenance: you own the domain list, the alert routing, and the edge cases (SNI mismatches, internal-only hosts, certs behind load balancers that differ from the origin).
Dedicated TLS monitoring handles the inventory, scheduling, and alerting for you. Tools purpose-built for infrastructure monitoring treat certificate expiry as a first-class check type alongside HTTP uptime and DNS resolution.
Overwatch includes TLS certificate monitoring on every plan. Add a hostname, set your warning threshold (for example, 30 days), and Overwatch checks the certificate on a regular schedule. When expiry approaches, alerts go to Slack, Discord, Teams, email, or any webhook you configure.
What alert thresholds should you use for SSL expiration?
A single alert on expiration day is an incident, not a warning. By the time a cert expires, you are doing emergency work on a weekend instead of a routine renewal during business hours.
Use a tiered alert ladder:
- 30 days out: Planning window. Enough time for procurement, approval chains, and manual renewals on longer-lived certs.
- 14 days out: Active renewal. Someone should be working the ticket, not just aware of it.
- 7 days out: Final warning. If renewal has not completed, escalate to paging or @channel in Slack.
Route early warnings to a low-priority channel. Reserve paging for the 7-day threshold or an expired state. Certificate renewal is rarely a drop-everything emergency at 30 days. It absolutely is at 24 hours.
Match thresholds to your renewal process. If your security team requires two weeks to approve a new cert, your first alert needs to fire before that window closes. If you use 90-day Let's Encrypt certs with automated renewal, your alerts should catch renewal failures, not just calendar dates.
How do you set up automated SSL certificate monitoring?
Treat certificate monitoring like any other production dependency: inventory it, automate checks, and test alerts before you need them.
Step 1: Build a complete domain inventory. List every hostname that serves HTTPS: primary domain, www, API subdomains, admin panels, webhooks, staging environments, and internal services behind load balancers. Cross-reference DNS records with your cloud provider's certificate manager. The cert that expires is always the one nobody remembered to add.
Step 2: Add a TLS check for each hostname. Configure one monitor per hostname (or per certificate if multiple domains share a single cert via SAN entries). Set check intervals to daily for expiry tracking. More frequent polling does not change the expiration date.
Step 3: Configure tiered alerts. Wire 30/14/7-day thresholds to the right channels. Test delivery with a dry run before relying on the alerts during a real renewal cycle.
Step 4: Monitor renewal jobs, not just dates. If you use automated renewal (certbot, ACME, managed cloud certs), add a heartbeat or log check that confirms renewal succeeded. A cert that should auto-renew but does not is the most common path to an expired production certificate.
Step 5: Review quarterly. Domains get added during launches and forgotten during decommissions. A quarterly audit of your TLS monitor list takes 15 minutes and prevents the "we shut down the service but left the cert monitor" confusion.
If you already run Overwatch for HTTP uptime, adding TLS checks keeps certificate expiry in the same dashboard and alert routing as your other monitors. One tool, one on-call rotation, one place to see what is about to break.
Frequently Asked Questions
How often should I check SSL certificate expiration?
Daily checks are enough for most certificates. Expiry dates change only when you renew or reissue a cert, so polling every minute adds noise without value. If you use 90-day Let's Encrypt certificates, daily checks still give you weeks of lead time before the 30-day warning threshold.
What alert thresholds should I use for SSL expiration?
Use a tiered ladder: 30 days for planning and procurement, 14 days for active renewal work, and 7 days as a final warning before expiry. A single alert on the expiration day is too late. Route early warnings to a team channel and reserve paging for the 7-day or expired states.
Can uptime monitoring detect expiring SSL certificates?
Basic uptime checks only verify that HTTPS works right now. They do not track how many days remain on the certificate. You need a dedicated TLS or SSL expiry monitor that reads the certificate's notAfter field and compares it to today's date.
How do I find all SSL certificates my company needs to monitor?
Start with your public-facing domains and subdomains: marketing sites, APIs, admin panels, and webhooks. Then add internal endpoints on load balancers, staging environments, and mail servers. Export DNS records and cross-reference with your cloud provider's certificate manager to catch certs that auto-renew in one place but not another.
What happens when an SSL certificate expires?
Browsers show a security warning and most users will not proceed. API clients and mobile apps may fail TLS handshakes entirely, breaking integrations silently. Search engines can downgrade trust signals for your domain. Recovery requires issuing a new certificate and deploying it, which can take hours if nobody was watching the expiry date.
An expired SSL certificate is a calendar problem that becomes an outage when nobody is watching the dates. Overwatch monitors TLS certificate expiration alongside HTTP, TCP, DNS, and cron job checks, with alerts to Slack, Discord, Teams, and webhooks. Add your domains once and get warned weeks before expiry, not hours after. Get started free →