SSL certificate expiry is one of the most preventable causes of production outages — and one of the most common. A certificate expires, HTTPS connections start failing, browsers show your users a red "Your connection is not private" warning, and revenue, trust, and search rankings all take a hit simultaneously. The fix takes minutes. The damage from missing the expiry can last days.
This guide covers how SSL certificate expiry causes outages, how to monitor certificates effectively, how to set up automated alerts before they expire, and how Vigilmon's SSL monitoring feature fits into a complete monitoring strategy.
Why SSL Certificate Expiry Causes Outages
An SSL/TLS certificate is a cryptographic document that:
- Proves your server's identity (you own the domain)
- Enables encrypted HTTPS connections between browsers and your server
- Has an expiration date — after which browsers and clients refuse to connect
When a certificate expires, every HTTPS connection attempt fails immediately. Browsers display a security warning that most users won't bypass. API clients throw TLS errors. Mobile apps can't connect to your backends. Third-party integrations that call your webhooks start failing.
The cascade is fast and comprehensive. Unlike most outages, an expired SSL certificate breaks all connections simultaneously across all clients — not just a subset.
Why Expiry Is So Commonly Missed
Let's Encrypt changed the mental model. Before Let's Encrypt, certificates were purchased annually and the renewal process was deliberate enough that teams kept track. Let's Encrypt made certificates free and automated renewal via ACME — which is excellent when it works, and dangerous when the auto-renewal process silently breaks without anyone noticing.
Certificates are infrastructure, not application code. Development teams are focused on the code they ship. Certificate renewal is an infrastructure concern that often lives in a different system, maintained by a different person, with no alerting when something goes wrong.
Test environments have expiring certs too. A staging certificate that expires can block your deployment pipeline at the worst possible time — right before a release when you need to push a fix.
Wildcard and multi-domain certificates cover many services. When a single certificate covers *.yourdomain.com and dozens of subdomains, its expiry takes everything down at once. The blast radius is larger than most teams expect.
How SSL Certificate Monitoring Works
SSL certificate monitoring checks your domain's certificate on a regular schedule and alerts you when the expiry date crosses a configurable threshold — typically 30 days, 14 days, and 7 days before expiry.
The check process:
- The monitoring tool opens a TLS connection to your domain on port 443
- It reads the certificate presented by your server
- It extracts the
Not After(expiry) field from the certificate - If expiry is within the configured alert window, it fires an alert
Some monitoring tools also check:
- Certificate chain validity: whether the full chain from your cert to a trusted root CA is intact
- Common name matching: whether the certificate covers the domain being checked
- Certificate revocation: whether the certificate has been revoked via OCSP or CRL
- Certificate authority: whether the issuing CA is trusted by major browsers
What Vigilmon's SSL Monitoring Covers
Vigilmon includes SSL certificate monitoring as part of its HTTP monitoring feature. When you set up an HTTPS monitor for any domain, Vigilmon automatically tracks the SSL certificate presented by that domain and alerts you before it expires.
Expiry Tracking
Vigilmon checks your certificate's expiry date on every monitoring cycle and surfaces it clearly in the monitor dashboard:
- Days remaining until expiry shown prominently
- Color-coded status: green (safe), yellow (warning zone), red (critical/imminent)
- Alert notifications when the certificate enters your configured warning window
Alert Channels
SSL expiry alerts route through the same channels as your uptime alerts:
- Email: Direct notification to configured recipients
- Webhook: POST to any URL — integrates with Slack, PagerDuty, OpsGenie, Discord, or custom handlers
This means you get SSL expiry warnings in the same Slack channel, the same on-call rotation, and the same incident workflow as your uptime alerts — no separate tool or configuration required.
Multi-Region Certificate Validation
Vigilmon's multi-region probe architecture means SSL checks come from multiple geographic locations. This matters because CDN and load balancer configurations can result in different certificates being served to users in different regions — a misconfigured certificate rotation that only affects European users, for example, shows up immediately in Vigilmon's per-probe data.
Zero-Downtime Certificate Change Detection
When you renew or rotate a certificate, Vigilmon detects the new certificate on the next check cycle. You can verify the new certificate's expiry date from the monitoring dashboard without manually running openssl commands against your server.
Setting Up SSL Certificate Monitoring with Vigilmon
Step 1: Create Your Account
Go to vigilmon.online and sign up. No credit card required. The free tier includes 5 monitors.
Step 2: Add an HTTPS Monitor
Click Add Monitor and select HTTP/HTTPS as the monitor type.
Enter your domain URL using the https:// scheme — for example, https://yourdomain.com or https://api.yourdomain.com. Vigilmon automatically enables SSL certificate tracking for any monitor using HTTPS.
Step 3: Configure Alert Thresholds
In the monitor configuration, set your SSL expiry alert thresholds:
- 30 days: First warning — enough time to investigate and renew without urgency
- 14 days: Escalated warning — renewal should be happening now
- 7 days: Critical — if auto-renewal is configured, investigate why it hasn't run
A three-tier threshold system gives you plenty of lead time while escalating urgency as the deadline approaches.
Step 4: Set Up Notification Channels
Configure where expiry alerts go:
- Email: Add one or more addresses to receive SSL expiry warnings
- Webhook: Paste a Slack incoming webhook URL, a PagerDuty events API URL, or your custom endpoint
Route SSL expiry alerts to the same channel as your uptime alerts so they're visible to the right people with the same urgency expectations.
Step 5: Add Monitors for All Critical Domains
Add monitors for every domain and subdomain running HTTPS:
- Primary domain (
https://yourdomain.com) - API domain (
https://api.yourdomain.com) - Auth domain (
https://auth.yourdomain.com) - Admin domain (
https://admin.yourdomain.com) - Any customer-facing subdomains
If you use wildcard certificates, monitor representative subdomains — if the wildcard cert expires, each monitored subdomain will independently alert.
SSL Certificate Monitoring Best Practices
Set Alert Windows That Give You Enough Time
The right expiry alert window depends on how your renewal process works:
- Auto-renewal (Let's Encrypt + Certbot): A 30-day warning gives you ample time to investigate why auto-renewal failed
- Manual renewal: A 60-day warning gives you time to procure, validate, and install the new certificate
- Organizational/enterprise CAs: CA-signed certificates from internal CAs may have longer procurement timelines — alert at 90 days
The goal is to alert early enough that renewal is an orderly process, not a fire drill.
Monitor Staging and Development HTTPS Endpoints
Certificate expiry in non-production environments is easy to overlook and can block deployments at the worst time. If your staging environment uses HTTPS — and it should — monitor it too. Route staging alerts to a low-priority channel rather than on-call, but make sure they're visible.
Don't Rely Solely on Auto-Renewal
Let's Encrypt auto-renewal via Certbot, Caddy, Traefik, or similar tools is reliable when configured correctly — but failures happen silently. Renewal scripts can break when:
- The domain's DNS changes and ACME validation fails
- A firewall rule blocks the renewal challenge response
- The renewal process runs as a user without write access to the certificate directory
- The cron job or systemd timer that triggers renewal stops running
External certificate monitoring is your safety net for when auto-renewal silently fails. It verifies the certificate that's actually being served — not just whether the renewal process thinks it succeeded.
Check the Full Certificate Chain
A certificate that validates on your local machine may present an incomplete chain to browsers and clients. Intermediate certificates are served by your web server configuration, not embedded in the leaf certificate. If your server is misconfigured to omit intermediate certificates, some clients will reject the connection even though the leaf certificate is valid and not expired.
When possible, configure your monitoring tool to validate the full certificate chain, not just the leaf certificate expiry date.
Test Alerts Before You Need Them
After configuring SSL monitoring, verify the alert path works:
- Temporarily set your expiry warning threshold very high (e.g., alert if expiry is more than 400 days away)
- Confirm an alert arrives in the expected channel
- Reset the threshold to your intended value
This confirms that when a real certificate approaches expiry, the alert will actually reach the right people through the right channel.
Audit All Your Domains Regularly
It's easy to lose track of certificates that were set up for specific features and then forgotten — a certificate on a legacy API subdomain, a third-party integration domain, or an old marketing site that still gets traffic. Run a regular audit of all domains your organization owns and verify each one has active monitoring.
What Happens When a Certificate Expires: A Timeline
Understanding the timeline of a certificate expiry incident helps calibrate alert urgency.
T-30 days: Certificate enters Vigilmon's warning window. Email and webhook alerts fire. Normal business hours to address.
T-14 days: Escalated alert. If auto-renewal hasn't run by now, something is wrong. Active investigation should be underway.
T-7 days: Critical alert. Every day without renewal increases risk significantly.
T-0 (expiry): Browsers start refusing connections. Users see "Your connection is not private" warnings. API calls fail with TLS errors. Revenue impact begins immediately for e-commerce sites and SaaS applications.
T+0 to T+hours: Renewal race. Certificate renewal is typically fast (minutes for Let's Encrypt), but propagating a new certificate through a CDN or load balancer can take 5–30 minutes. During this window, users on cached connections may get varying behavior.
T+days: Reputation and search ranking damage. Google Search Console registers the downtime. Users who encountered the error may not return. Negative reviews may reference "security issues" even after the certificate is restored.
The earlier you alert, the more orderly the renewal process, and the lower the probability of any user impact.
SSL Monitoring as Part of a Complete Monitoring Strategy
SSL certificate monitoring is one piece of a complete monitoring setup. The full picture for a production web application:
| Monitor Type | What It Catches | Vigilmon Feature | |---|---|---| | HTTP/HTTPS uptime | Service availability | HTTP monitor | | SSL certificate expiry | Certificate expiry before it causes outage | Automatic with HTTPS monitor | | TCP port | Database, message queue availability | TCP monitor | | Heartbeat | Cron job and background worker failures | Heartbeat monitor | | Response time trends | Degradation before it becomes an outage | Response time history |
SSL monitoring without uptime monitoring is incomplete. An HTTPS endpoint that returns a valid certificate but a 502 error isn't serving your users. Vigilmon's HTTP monitors check both: TLS handshake success (certificate validity and expiry) and response status code (service availability).
Common SSL Monitoring Mistakes
Monitoring only the primary domain. Wildcard certificates cover subdomains, but that doesn't mean every subdomain is automatically covered by your monitoring. Explicitly monitor subdomains that serve real users.
Relying only on your CA's email reminders. Certificate authorities send expiry reminder emails — but to the email address on record when the certificate was purchased. If team composition has changed, that email may be going to someone who no longer works on the infrastructure. External monitoring with current alert routing is more reliable.
Not monitoring after certificate rotation. After renewing a certificate, verify that the new certificate is being served correctly: check the expiry date, verify the common name covers all required domains, and confirm the chain is complete. Your monitoring tool should detect the change automatically, but a quick manual verification after rotation catches misconfigurations immediately.
Setting only a 7-day warning window. Seven days sounds like plenty of time, but if the alert fires on a Friday, you may be dealing with it over the weekend. A 30-day window gives you comfortable working-hours time to address the renewal.
Conclusion
SSL certificate expiry is a fully preventable outage category. Every step of the failure path — missed renewal, silent auto-renewal failure, surprise expiry — can be caught weeks in advance with the right monitoring in place.
Vigilmon's SSL certificate monitoring is built into every HTTPS monitor: no separate configuration, no extra cost, multi-region validation that catches certificate misconfigurations across geographies. Combined with Vigilmon's uptime monitoring and heartbeat checks for background jobs, it covers the full failure surface of a production web application.
Set up monitoring once. Get alerted with weeks of lead time. Renew without drama.
Try Vigilmon free at vigilmon.online — 5 monitors, SSL monitoring included, no credit card required.
Tags: #ssl #monitoring #devops #security #uptime #certificates #webdev