How to Set Up SSL Certificate Expiry Alerts So You Never Get Caught Off Guard

It is 8:47 AM on a Monday. Your phone starts buzzing. Customers cannot reach your site. Stripe webhooks are failing. Your support inbox is filling up with screenshots of a red browser warning that reads "Your connection is not private." You check your certificate. It expired at 2:13 AM on Sunday.

Nobody was watching. Nobody got paged. The cron that was supposed to renew it silently failed 11 days ago, and the renewal window quietly closed over the weekend. Every minute the site stays broken costs revenue, search ranking, and trust. This is the most preventable outage in all of web operations, and it still happens to serious companies every single week.

This tutorial walks through how to set up SSL certificate expiry alerts the right way, the 30-15-7 day alert rule that gives you enough runway to fix problems, the gotchas that catch most teams, and a concrete step-by-step walkthrough so you never wake up to this scenario.

Why SSL Expiry Is a Silent Killer

An expired SSL certificate does not take your server offline. The site is still serving pages. The database is still responding. From a server-monitoring point of view, everything looks green. That is exactly what makes it so dangerous. The failure happens inside the browser, between your customer and the little padlock icon they have been trained to look for.

Here is what actually breaks the moment a certificate expires, by audience.

WooCommerce and Shopify storefronts

Checkout stops. Chrome and Safari block the flow with a full-page warning. Stripe, PayPal, and most payment providers refuse to load their iframes on pages served with an invalid certificate. Every abandoned cart is real lost revenue, and a fraction of those shoppers never come back. If you run an ecommerce site, expired SSL is a direct revenue outage. See our guides on monitoring for WooCommerce and monitoring Shopify store uptime.

WordPress site owners

The admin login page stops working for anyone with modern security settings. Logged-in users lose their sessions because the browser refuses to send cookies marked Secure over an untrusted connection. Plugins that call back to your own REST API start failing silently. Readers who reach the site see a scary warning and bounce, which search engines interpret as a negative quality signal. See our WordPress monitoring guide for other WordPress-specific failure modes we catch.

WHMCS and cPanel resellers

Client portals go dark. Your customers cannot pay invoices, open tickets, or manage their services. Any API integration with billing, domain registrars, or provisioning scripts breaks because curl and most SDKs reject expired certificates by default. Auto-billing may still run in the background, but self-service dies the moment customers see the browser warning. Our WHMCS monitoring guide covers the portal-specific gotchas SSL checks should catch.

SaaS founders

Every signup form, every OAuth callback, every webhook from Stripe or GitHub, every mobile app talking to your API. All of it fails closed. API clients do not click through browser warnings. They fail the TLS handshake and throw an exception. You lose events you will never get back, and unlike a 500 error, the failure mode looks scary to the end users who do reach a page. You do not just lose traffic. You lose trust.

If this is your first time setting up monitoring in general, our beginner's guide to website monitoring covers the fundamentals you will want alongside SSL checks.

Pick a Threshold That Gives You Runway

The best SSL monitoring setup does not wait until the certificate has already expired. It warns you well before, so you always have time to act. Here is how to think about the threshold.

30 days out: the "there is a problem" heads-up

If auto-renewal is working correctly, you should never see a 30-day warning. When you do, it means something is stuck. Maybe the Let's Encrypt renewal hook is failing. Maybe the DNS validation record is missing. Maybe a paid certificate is genuinely about to expire and nobody ordered the replacement. At 30 days you have time to dig into the root cause, coordinate with whoever owns DNS, and avoid emergency work. This is the humane threshold for most sites.

14 days out: the "act this week" point

At 14 days, auto-renewal is not going to save you. Put a task on the calendar for the current week. For paid certificates, start the order now. Validation emails and domain verification can take a few business days, especially for wildcard or EV certificates. This is also Velprove's default threshold when you enable SSL alerts on a monitor.

7 days out: the "stop what you are doing" line

Under 7 days is a real incident in slow motion. Renewal has failed repeatedly or nobody is watching earlier warnings. Page the on-call person. Follow the incident response playbook at the end of this post. Do not wait for Monday morning.

Why does the threshold matter? Because "expires in 7 days" is too close to the cliff if the alert fires on a Friday evening. You may not have a DNS provider, hosting account, or domain registrar available to fix the root cause before the weekend. Thirty days is the humane choice if you want breathing room. Fourteen days is the default. Seven days is the last line of defense.

Common Gotchas That Catch Site Owners Off Guard

SSL looks simple on paper. Renewal is automatic, right? In practice these are the traps we see most often.

Wildcard certs that do not cover what you think

A wildcard certificate for *.example.com covers every subdomain at one level, but it does not cover the apex domain on its own, and it does not cover nested subdomains like api.v2.example.com or staging.api.example.com. Many owners assume the wildcard protects everything. It does not.

Fix. Run openssl s_client -connect host:443 -servername host for every public hostname and confirm the cert returned matches. Add a monitor for each one.

Let's Encrypt auto-renewal failures

The most common failure modes are a stopped Certbot systemd timer, a cron job that was deleted during a server migration, Let's Encrypt rate limits after repeated failed attempts, DNS challenge misconfiguration, and firewall rules that block inbound traffic on port 80 for the HTTP-01 challenge. The cron job keeps running. The certificate keeps not renewing.

Fix. Run sudo certbot renew --dry-runmonthly to catch silent failures. Do not trust that "it worked last time" means it will work next time. An external monitor is the only honest signal.

Broken intermediate certificate chains

A certificate can be valid while the intermediate chain is broken. Your leaf cert validates, but browsers cannot build a path back to a trusted root. Firefox and Chrome handle this differently, so it may work in one browser and fail in another. This breaks most often when someone manually installs a cert from a reseller and forgets to include the full chain bundle.

Fix. Test with SSL Labs and require a grade of A or better. Your web server config must serve the full chain, not just the leaf.

Subdomain coverage gaps

You add a new subdomain for a marketing campaign or an API v2 endpoint, and nobody remembers to add SSL monitoring for it. Six months later, that subdomain's certificate expires and nobody notices because it was never monitored in the first place. Most teams monitor www.example.com and forget that shop.example.com, app.example.com, and status.example.com all have their own certificates with their own expiry dates.

Fix. Whenever DNS adds a new record that terminates TLS, add a Velprove monitor in the same change. Make it part of your checklist, not an afterthought.

Non-HTTPS fallback URLs

Some legacy WordPress plugins and WHMCS modules call HTTP endpoints internally when HTTPS fails. Users think everything is fine because the page loads, but they are now transmitting cookies, form data, and session tokens in the clear. This is worse than an outage because it silently exposes users without anyone noticing.

Fix. Use HSTS with a long max-age and include the apex domain. Configure your monitors to fail hard on HTTP fallback rather than treating it as a successful response. Least-privilege thinking applies here. Never allow an HTTP path that serves real content.

How Velprove Monitors SSL Without Extra Setup

Velprove does not have a separate SSL monitor type. SSL expiry monitoring is a toggle on every HTTPS monitor. You enable it with one checkbox when you create or edit the monitor, pick a threshold in days (default 14, range 1 to 90), and the check captures the certificate issuer, expiry date, and days remaining on the same connection as the regular health check. No extra cost, no extra configuration, and no extra load on your server.

When your certificate is inside your configured threshold but not yet expired, Velprove flags the monitor as degraded. The dashboard shows a warning and the daily summary email surfaces it, without anyone getting paged at midnight. If you also want active notifications (to Slack, Discord, Teams, or email) at that threshold, toggle Alert on degraded status on the monitor. When the certificate actually expires, the status flips to down and a regular outage alert fires through all your configured channels.

A monitor runs from one region of your choice (5 available: NA, EU, UK, Asia, OCE). If you want multi-region SSL coverage, create one monitor per region pointing at the same URL. This catches region-specific issues like geo-routed CDNs serving different certificates in different markets. And because we catch real failures that plain HTTP monitors miss (like an intermediate chain break that still returns 200 OK) while ignoring fake failures that other tools false-alarm on, you only hear from us when something actually needs fixing.

Step-by-Step Setup in Velprove

1. Create a free account. Go to velprove.com/register. No credit card required.
2. Add a monitor. Click New monitor, pick HTTP as the type, and paste your HTTPS URL. Use the full hostname you want to check, including www. if that is what users hit.
3. Pick your region. One region per monitor. Choose the region closest to your customers, or create multiple monitors for the same URL in different regions if you want global coverage.
4. Enable SSL expiry alerts. In the monitor settings, toggle SSL expiry alerts on and pick a threshold. The default is 14 days. We recommend 30 days for most sites, 45-60 days if you have EV certs or complex DNS validation.
5. Turn on degraded alerts (optional). If you want an active notification when the threshold is crossed (not just a dashboard badge), toggle Alert on degraded status on the monitor. Without this, you only see the degraded status on the dashboard and in the daily summary email.
6. Configure alert channels. Email is free and always on. Starter and Pro plans add Slack, Discord, Microsoft Teams, and webhooks for PagerDuty or your own systems.
7. Repeat for every HTTPS hostname. Apex domain, www, api, admin, staging, any subdomain that terminates TLS. Do not rely on a single wildcard monitor to cover everything.
8. Add the monitor to your status page. Public transparency about SSL health is a quiet trust signal for customers and auditors.

Incident Response When the Alert Fires

A degraded SSL alert at 30 days is not a drop-everything moment, but it deserves a triage pass within the same business day. Here is the playbook.

1. Confirm the certificate is actually the problem. Run openssl s_client -connect yourdomain.com:443 -servername yourdomain.com from your laptop. Check the notAfter date in the output. Make sure you are looking at the cert your server is actually serving, not a cached version.
2. Check which renewal method owns it. Certbot, acme.sh, cPanel AutoSSL, Cloudflare, a managed WordPress host, or a paid CA. You can only fix the right thing once you know who is supposed to renew.
3. If Let's Encrypt, force a renewal. Run certbot renew --force-renewal on the server, or the equivalent in your panel. Watch the logs at /var/log/letsencrypt/letsencrypt.log. Most failures are port 80 being blocked, a webroot path mismatch, or DNS validation not completing.
4. If paid, order the replacement immediately. Do not wait for the reseller's approval email. Start the CSR generation now. EV and wildcard certs can take 2 to 5 business days to issue.
5. Install the full chain, not just the leaf. Most brown-paper-bag moments come from pasting only the certificate without the intermediate bundle. Validate with SSL Labs before closing the incident.
6. Verify from outside your network. Do not just refresh your own browser. Use a different network, a different device, and ideally a different geographic region. Velprove's five global regions do this automatically.
7. Write a one-paragraph post-mortem. What broke, why the 30 day alert did not help, and what you changed so it cannot happen again. Ten minutes of writing saves the next repeat.

Frequently Asked Questions

How often should I check SSL certificate expiry?

Every regular uptime check can also verify SSL expiry once you enable it on the monitor. At minimum, check daily. Weekly is risky because a Let's Encrypt renewal can fail for seven straight days and leave you with less than a week to respond. A 1 to 5 minute interval on your main HTTPS URLs means you get visibility within minutes of a renewal breakage.

What happens when an SSL certificate expires?

Modern browsers block access with a full-page security warning. Users cannot reach the site without clicking through a scary interstitial. WooCommerce checkout stops processing orders. WHMCS client portals refuse logins. API clients reject the TLS handshake and fail silently. Search engines may drop rankings. Expired SSL is a full outage for any transactional website.

Does Let's Encrypt auto-renewal always work?

No. Auto-renewal fails more often than people expect. Common causes are a stopped cron or systemd timer, rate limits after repeated failures, DNS challenge misconfiguration, firewall rules blocking the ACME challenge, and filesystem permission changes. Never trust auto-renewal without an independent external monitor verifying the actual live certificate expiry date.

Should I monitor subdomains separately for SSL?

Yes. Wildcard certificates only cover one level of subdomain. A cert for *.example.com covers app.example.com but not api.staging.example.com. If you have separate certificates for www, api, cdn, admin, or any client-facing subdomain, each one needs its own monitor. Missing one is a common cause of surprise outages.

Does Velprove charge extra for SSL monitoring?

No. SSL expiry monitoring is included on every plan, including the free plan. Toggle SSL expiry alerts on any HTTPS monitor, pick a threshold between 1 and 90 days, and when your certificate falls inside that window, the monitor flips to degraded status. When the certificate actually expires, it flips to down and fires a regular outage alert. There is no separate SSL monitor to configure.

Start Monitoring SSL Expiry in Under 2 Minutes

If you have ever been woken up by an expired certificate, you know this is the easiest outage class to prevent. A sensible threshold gives you runway. An independent external monitor gives you truth. Velprove gives you both, on the free plan, with no setup beyond pasting in a URL.

Create your free Velprove account, add your HTTPS URLs, enable SSL expiry alerts, and set the threshold that matches your risk appetite. Ten monitors, five global regions to choose from, SSL expiry alerts, and one free browser login monitor included. Next Monday morning, your phone will not be buzzing.