How to Track SSL Expiry Across All Your Client Websites

Why SSL expiry is harder to track than it looks

SSL certificate expiry sounds like a simple operational task: know when each certificate expires, renew it before that date, move on. In practice, agencies managing client portfolios discover that the difficulty scales faster than the client count.

The core problem is not the renewal itself — most certificates can be renewed in under five minutes. The problem is knowing that a renewal is needed before the site goes down, across a portfolio that combines dozens of different hosts, registrars, certificate authorities, and client-managed configurations.

At 10 clients, a shared spreadsheet updated monthly is manageable. At 40 clients, the spreadsheet falls behind. At 80 clients, someone is inevitably working from data that is weeks out of date, and the first sign of a missed renewal is a panicked email from a client saying their site is showing a certificate error.

The 47-day SSL certificate change coming in phases from March 2026 makes this worse by a factor of eight. Agencies that have managed SSL tracking through informal workflows need to systematise before the renewal frequency makes it impossible.

What SSL tracking actually requires

Tracking SSL expiry well means answering three questions for every domain in your portfolio, at any moment:

1. What is the current expiry date of the SSL certificate? Not the date from the last time you checked — the current date, because certificates can be replaced at any time by a client, a hosting platform, or an automated renewal.
2. Is auto-renewal configured and working? A certificate that is set to auto-renew can still expire if the renewal mechanism has silently failed.
3. How much runway remains? Not just "does it expire this month" but "given the renewal mechanism and the new 47-day validity window, is there enough time to investigate if the next renewal fails?"

Answering these questions for a 60-domain portfolio once a month is feasible. Answering them daily, for every domain, is only feasible with automated checking.

For the complete certificate monitoring workflow, use the SSL monitoring Watchtower guide.

Building your domain inventory

Before you can track SSL expiry, you need a complete and accurate list of the domains you are responsible for. This is less obvious than it sounds.

Common inventory gaps

Subdomains: A client with example.com often also has shop.example.com, mail.example.com, and app.example.com. Each is a separate certificate (unless you are using a wildcard). Agencies frequently track the apex domain and miss the subdomains.

Staging and development environments: staging.example.com and dev.example.com also need valid SSL certificates. An expired certificate on a staging domain blocks your own team's review process. These environments are often excluded from monitoring because "they're internal" — until a client tries to access staging to review a deployment.

Redirects: www.example.com redirected to example.com still serves an SSL certificate for the initial request. If that certificate expires, browsers show a warning before the redirect fires.

Client-managed domains: Clients occasionally add or remove domains independently. A client who registers a new domain for a product launch and points it at your server may not tell you. Build a discovery process — at minimum, a quarterly check of DNS records pointing to your infrastructure.

Organising your inventory

A workable domain inventory for SSL tracking needs, at minimum:

| Field | Why it matters | |---|---| | Domain (apex + subdomains) | The unit you are monitoring | | Certificate issuer | Determines renewal mechanism and expiry notification channels | | Renewal mechanism | Manual, Let's Encrypt/ACME, managed hosting, CDN | | Who controls DNS | You, client, third-party registrar | | Client name | For grouping and reporting | | Hosting account reference | So you can find the right control panel when a renewal fails |

Monitoring approaches: manual, semi-automated, and fully automated

Spreadsheet with manual checks (under 20 domains)

At small scale, a shared spreadsheet with a column for expiry date and a monthly reminder to check each domain in a browser is functional. Chrome and Firefox both surface certificate expiry in the lock icon, and the OpenSSL command line gives exact dates:

openssl s_client -connect example.com:443 </dev/null 2>/dev/null | openssl x509 -noout -dates

The limits: the data is as stale as the last time someone ran the check, you have no alert when a certificate is near expiry, and there is no history to show clients.

Cron jobs and scripts (20–60 domains, technical teams)

A simple shell script looping through a list of domains and calling openssl s_client can check certificate expiry automatically. Set it to run daily via cron and pipe results into a Slack channel or email. This works — until it does not: servers go offline, cron jobs drift, the list of domains gets out of sync with the actual portfolio.

The deeper issue is that checking from your own infrastructure does not catch CDN-layer certificate problems visible only from the public internet. If a client's Cloudflare certificate is expiring while the origin certificate Certbot is managing looks fine, a cron job checking from your server will not surface it.

Dedicated monitoring tools (60+ domains, or pre-47-day preparation)

For agencies managing more than a few dozen domains — or any agency preparing for the 47-day SSL era — a dedicated SSL monitoring service checks each domain from external infrastructure, stores historical data, and alerts reliably when action is needed.

The key operational difference from DIY approaches is that the check is external: it verifies what a browser would see, not what your server thinks is happening. This surfaces CDN certificate issues, proxy mismatches, and cases where the server is serving an expired certificate despite your monitoring script reporting it as valid.

Setting alert thresholds that work for short-lived certificates

At 398 days, a 30-day warning was reasonable

With annual certificates, a 30-day alert gave you a month to investigate and act before expiry. Most teams could fit that into a normal workflow.

At 47 days, 30 days is most of the certificate lifetime

If you alert at 30 days on a 47-day certificate, you are alerting during the first week of its life. That produces constant noise and leads teams to ignore alerts. The threshold needs to be recalibrated.

Recommended thresholds for 47-day certificates:

| Alert level | Days remaining | Action | |---|---|---| | Info | 20 days | Note in daily digest — within normal renewal window | | Warning | 14 days | Verify auto-renewal is queued; investigate if not | | Critical | 7 days | Immediate investigation required | | Emergency | 3 days | Escalate — certificate will expire before next weekly check |

With daily monitoring, a 14-day warning window gives you two full weeks to investigate a renewal failure before it causes downtime. At 47-day lifetimes, that is the minimum viable window.

Connecting SSL monitoring to your client reporting workflow

SSL expiry data is most useful when it feeds into the reporting your clients already receive. A monthly report showing current SSL status across their domains — alongside domain registration dates, DNS health, and uptime notes — is a concrete artefact that demonstrates your ongoing oversight.

See the client website health report template for a format you can adapt for client deliverables. For domain registration monitoring alongside SSL, see domain expiry monitoring for agencies.

What CertPilot tracks for you

CertPilot checks every domain in your account daily and surfaces the data you need to stay ahead of SSL expiry at scale:

• Current certificate expiry date checked from external infrastructure, not your server
• Certificate issuer so you know which renewal mechanism is in play
• Days remaining with configurable alert thresholds
• DNS health checks to catch misconfigurations that block auto-renewal
• Domain registration expiry so you catch registration lapses before they become SSL problems
• Client grouping for portfolio-level views and per-client reporting

Start a 14-day free trial — no credit card required — or run a free audit for up to 10 domains right now with no account needed.

External references

• SSL Labs SSL Test — manual certificate inspection tool from Qualys
• CA/Browser Forum Ballot SC-081 — the 47-day timeline
• Let's Encrypt expiry notifications — how Let's Encrypt alerts work (and why they are not enough for agencies)

Related resources

• CertPilot Watchtower
• 47-Day Renewal Pre-Flight
• SSL monitoring for web agencies
• How CertPilot checks domains

Frequently Asked Questions

What should agencies track for SSL expiry?

Agencies should track the live certificate expiry date, days remaining, issuer, hostname coverage, renewal mechanism, DNS owner, and client owner.

To track SSL expiry across client websites reliably, the data should come from current live checks rather than stale spreadsheet entries.

Is uptime monitoring enough to catch SSL expiry?

No. Uptime monitoring may tell you whether a site responds, but it does not always give the agency the SSL renewal context needed for client-domain operations.

SSL tracking should confirm the certificate visitors receive, how soon it expires, and who needs to act if renewal fails.

How often should agencies check client SSL expiry?

Daily checks are a practical baseline. They give the team enough runway to investigate renewal failures, DNS validation issues, or client ownership gaps.

Monthly manual checks become risky as certificate lifetimes shorten and renewal events happen more often.

Can agencies monitor SSL across multiple client domains?

Yes. The workflow should start with a complete inventory that includes apex domains, www variants, important subdomains, redirects, and client-managed domains.

Grouping by client makes the work manageable and supports monthly domain health reports.