How to Monitor SSL Certificate Expiration: Step-by-Step Setup

Quick answer

To monitor SSL certificate expiration, add your domain to a monitoring tool like PingPing, set your alert threshold (14, 7, 3, 1 day(s) before expiry or at expiry), then setup at least two notification channels from email, SMS, Slack, or webhooks. PingPing checks your certificate daily and warns you well in advance, so you can renew before browsers start showing security warnings to your visitors.

What you need before you start

Setting up SSL certificate expiry monitoring takes under five minutes. Here’s the short list:

• A public HTTPS website or API endpoint (PingPing connects to port 443 by default)
• The domain name you want to track (just the URL, no certificate files to upload)
• A PingPing account (a free 14-day trial covers everything you need to follow this guide)
• An email address, Slack workspace, or phone number for alerts

You don’t need server access. You don’t need to install anything. You don’t need to touch your web server config. SSL monitoring works the same way a browser does: it opens a TLS handshake, reads the certificate chain, and inspects what’s there.

Step-by-step: monitor SSL certificate expiration in PingPing

Step 1: Add your website to PingPing

Open the PingPing dashboard and click Add website. Paste your full URL, including https://, and give it a name you’ll actually recognize later. “Marketing site.” “Production API.” Whatever helps when you’re scanning a list of 20 monitors at 2am.

Hit save. That’s the whole step.

What goes wrong: People sometimes paste an HTTP URL by mistake (http://example.com). PingPing will still monitor it for uptime, but there’s no SSL certificate to check on plain HTTP. Make sure the protocol is https://. Also double-check the host. If your site is www.example.com, monitoring just example.com means the apex domain’s certificate gets checked, which might or might not be the one your visitors actually hit. When in doubt, add both.

Step 2: Confirm SSL monitoring is enabled

PingPing turns on SSL monitoring automatically when it detects an HTTPS endpoint. You don’t need to flip a switch. Still, check the monitor’s line on the dashboard and verify the SSL section shows green.

If you click on the Statuspage icon for your monitor (the little graph icon), and hover over the SSL Certificate status, you’ll see the certificate’s current expiry date, the issuer (Let’s Encrypt, Sectigo, DigiCert, GoDaddy, whoever), and algorithm used. If anything looks off here on day one, fix it before you continue. There’s no point setting up expiry alerts on a certificate that’s already misconfigured.

Step 3: Set your expiration alert threshold

This is the most important part of the setup, and it’s the part most people get wrong by configuring it once and never revisiting.

In the monitor’s settings, you’ll see a Certificate Health Check block. threshold options: 14 days, 7 days, 3 days, 1 day before expiry or only at expiry. Pick the one that matches how you actually renew certificates.

Here’s how I’d think about it:

• Auto-renewal in place (Let’s Encrypt via certbot, Caddy, Cloudflare, Vercel, Netlify, most modern hosts): 3 days is fine. Most of those renew at 7 days, so the cert should already be renewed by then, and the alert is really the safety net telling you the automation failed.
• Manual renewals through a commercial CA like DigiCert, Sectigo, or GlobalSign: go with 14 days so you have time to request, validate, install, and test before the old cert runs out.
• Mixed environments where you manage some certs and a hosting provider handles others: set 14 days for the manual ones and 7 days for the automated ones. Different thresholds per monitor is the point.

If you’re on a small team where one person handles infrastructure, set the threshold longer than you think you need. The day your cert is about to expire is always the day you’re on vacation or stuck on a delayed train.

Step 4: Configure your notification channels

PingPing supports multiple notification channels for SSL alerts: email, SMS, Slack, Discord, Telegram and webhooks. Pick at least two. The one time your certificate actually expires will be the one time you didn’t check your email.

A setup that works well for most small teams:

1. Email to a shared inbox like alerts@yourcompany.com so anyone on the team can see and acknowledge it.
2. Slack channel dedicated to alerts. Don’t put SSL alerts in #general (they get lost). Create #monitoring or #alerts and route everything there.
3. SMS to one person on-call for revenue-critical sites. SMS is the channel you can’t ignore, so save it for production where an outage actually costs you.
4. Webhook to your incident management tool (PagerDuty, Opsgenie, BetterStack, Zapier) if you have one. The webhook payload includes the certificate’s expiry date, the domain, and the issuer, so you can route alerts based on those fields.

To add a channel, open Notifications in your PingPing account, click Add notification, pick the type, and authenticate or paste your details. For Discord and Slack, you’ll provide the webhook. For Telegram you provide the channel name. For webhooks, paste the receiver URL; PingPing handles retries and request signing if you turn signing on.

Step 5: Test the alert before you trust it

This is the step almost everyone skips and later regrets. Trigger a test alert from the notifications panel. Make sure the email lands in your inbox (and isn’t sitting in spam, which happens more than you’d expect with noreply@ senders). Verify the Slack message shows up in the right channel. Confirm your phone got the SMS.

If you use a webhook, check that your receiver actually parsed the payload correctly. PingPing sends a structured JSON body; make sure your downstream system reads the right fields.

Once you’ve seen a test alert hit every channel you configured, setup is done. PingPing now runs daily SSL certificate expiry monitoring on this domain alongside its 30-second uptime checks.

What to do when a cert is about to expire

You got the alert. The countdown started. Here’s the order of operations.

If you’re on Let’s Encrypt with auto-renewal, log into the host that runs the renewal job. Check the cron schedule (certbot renew should run twice a day on most setups) and look at the most recent log. Renewals typically fail for a few reasons: DNS validation broke after a domain change, port 80 got firewalled so HTTP-01 can’t complete, the renewal script is running without the file permissions it needs, or the DNS provider API token used for DNS-01 expired. Fix the root cause, then force a renewal manually with sudo certbot renew --force-renewal.

If you’re on a managed platform (Vercel, Netlify, Cloudflare, Heroku, Render), check the SSL section of your platform dashboard first. Often the certificate is already renewed and the issue is that the new cert hasn’t propagated to the edge yet. Wait an hour, then re-check. If it’s still showing the old expiry, contact platform support; most fix this within hours when flagged.

If you bought the cert from a commercial CA, log into your account at the CA, request the renewal, complete domain validation (email, DNS TXT record, or HTTP file, depending on what you set), download the new certificate plus the intermediate chain, and replace the files on your server. Restart the web server. Verify on the command line with:

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com \
  | openssl x509 -noout -dates

You should see the new notAfter date.

If something goes badly sideways during a renewal and your site goes down, our downtime playbook walks through the recovery steps.

Common mistakes to avoid

A few things that cause real pain in practice:

• Treating SSL monitoring as a one-time setup. People configure it once and never revisit the channel list. Then someone leaves the team, their email bounces, and the alert never reaches anyone. Audit your notification channels every quarter.
• Setting the threshold too short. 3 days sounds responsive but assumes you’ll see the alert immediately. If it lands on a Friday night before a long weekend, you’ve got a problem. Default to longer windows unless your renewals are fully automated and battle-tested.
• Only monitoring the apex domain. If your customer-facing app lives on app.example.com and you only monitor example.com, you’re checking the wrong certificate. Add every hostname that visitors actually hit.
• Ignoring chain validation warnings. PingPing flags incomplete certificate chains as part of its daily checks. Some teams dismiss these because “the site loads fine on my laptop.” It does, because your laptop has cached intermediates. Users on certain Android versions, corporate networks, and older browsers won’t. Fix chain warnings on the day you see them.
• No backup notification path. Email alone isn’t enough. Mail servers go down. Filters tighten. Inboxes get buried. Always have a second channel that can reach you.

Tips from running this in production

A few things I’ve learned from monitoring my own certificates and watching how PingPing customers use the product.

The most common cause of an unexpected expiry isn’t the certificate authority screwing up. It’s a hidden subdomain nobody remembered to add to the monitor. Marketing spun up promo.yoursite.com for a campaign, used a separate cert, and never told ops. The cert silently expires after the campaign ends. Then someone reuses that subdomain a year later and the browser shows a warning that lingers in cached SEO snapshots.

Audit your DNS records once a quarter. For every subdomain that resolves, make sure it’s either tracked in your PingPing monitor list or has been retired and pointed nowhere.

The second-most-common cause is auto-renewal silently failing because port 80 got firewalled. Let’s Encrypt’s HTTP-01 challenge needs port 80 open. Plenty of teams close port 80 thinking “we’re HTTPS-only, who needs it.” Then 90 days later the renewal can’t complete and the cert expires. If you use HTTP-01, keep port 80 open and configured to redirect to HTTPS, not to block it. If you can switch to DNS-01 validation, that sidesteps the problem entirely.

And one more thing: when you set up monitoring, write down somewhere (a runbook or the README of your infrastructure repo) which certificates are managed by which system. Future you, debugging at 2am on a Saturday, will thank present you for the five minutes it took.

FAQ

How often should SSL certificates be checked? Daily. Certificates change infrequently, so checking every 30 seconds adds noise without value. PingPing runs SSL checks once a day, which still catches every expiration with weeks of lead time. By contrast, uptime monitoring needs 30-second intervals because servers can go down at any moment.

How many days before SSL expires should I renew? For automated renewals (Let’s Encrypt and similar), 3 days of buffer is plenty. For manual renewals through a commercial CA, give yourself at least 14 days to request, validate, install, and test.

Can I monitor SSL certificates for free? A handful of tools offer limited free SSL monitoring. PingPing includes SSL certificate expiry monitoring on every paid plan starting at €6/month, with no SSL add-on fee, plus uptime monitoring, response time tracking, and status pages bundled in. Some competitors gate SSL behind a higher tier - see how PingPing compares to Pingdom for the price-per-feature math.

What happens if I miss the SSL expiration alert? Your certificate expires and browsers start showing a full-screen “Your connection is not private” warning to every visitor. API integrations that validate SSL (payment webhooks, third-party syncs) stop working. The real cost of website downtime compounds quickly. This is why multiple notification channels matter.

Does SSL monitoring work for internal certificates? PingPing monitors any HTTPS endpoint reachable from the public internet. Truly internal certificates (behind a VPN) aren’t reachable, so they’re outside the scope of a SaaS monitoring tool. For everything publicly accessible (which is most production traffic), PingPing handles it.

Where to go next

If you want the full picture of what SSL monitoring covers (chain validation, protocol checks, tool comparisons), read the SSL certificate monitoring pillar guide. It’s the deep-dive this tutorial sits under.