The worst way to find out a client's SSL certificate expired is from the client.
It usually arrives as a screenshot. "Your connection is not private." Sent on a Monday morning, with a question you do not want to answer: "Is our site hacked?"
It is not hacked. A certificate lapsed, or renewed and never deployed, on a site you built two years ago and have not touched since. The fix takes ten minutes. The damage to the relationship takes longer, because from the client's point of view, you are the web people, and you did not know.
This guide covers why SSL failures keep catching agencies off guard, why auto-renewal is not enough, and how to set up SSL certificate monitoring across every client site so you hear about it first.
If you need to check one certificate right now, use the free SSL Expiry Checker.
Why SSL is an agency problem, not just a client problem
A single business with one website can get away with trusting its host. An agency cannot, for three reasons.
You manage certificates you did not set up. Client sites arrive with history. One uses Let's Encrypt through the host. One has a certificate a previous developer bought and installed by hand. One sits behind Cloudflare. One is on a platform that handles SSL for you, until a DNS change breaks provisioning.
Renewal ownership is unclear. Is the client's host renewing it? Your team? A plugin? The freelancer who left last year? When nobody is sure, nobody is watching.
The client blames you either way. Even when the host's renewal failed, the client's question is "why didn't you catch it?" For an agency, being first to know is the service.
Certificate lifetimes are shrinking fast
This is about to get harder. Under the CA/Browser Forum's schedule, the maximum lifetime of a public TLS certificate:
- Dropped to 200 days for certificates issued from March 15, 2026
- Drops to 100 days from March 15, 2027
- Drops to 47 days from March 15, 2029
At 47 days, every client certificate renews roughly eight times a year. Across 40 client sites, that is over 300 renewal events a year, and every one of them is a chance for a renewal to fail or a new certificate to never reach the live server. Calendar reminders stop being viable. Automation is the only answer, and automation needs something watching it.
Auto-renewal is not SSL monitoring
Most agencies assume auto-renewal has it covered. It covers the renewal. It does not cover the result.
| Auto-renewal | Live SSL monitoring |
|---|---|
| Requests a new certificate before expiry | Checks the certificate the live site is actually serving |
| Runs inside the host, CDN or plugin | Runs independently, from outside |
| Reports that renewal succeeded | Confirms visitors are receiving the new certificate |
| Fails silently if its own config breaks | Alerts you when expiry gets close, whatever the cause |
The gap between those two columns is where agencies get burned. Common examples:
- The host renewed the certificate, but a proxy or load balancer is still serving the old one.
- A client moved DNS to a new provider and automatic provisioning quietly stopped.
- The main site is covered, but
shop.client.comwas never part of the renewal setup. - The renewal plugin was deactivated during a site update and nobody noticed.
In every case, renewal "worked" as far as any dashboard shows. The browser warning appears anyway.
The rule: one system renews the certificate, a different system checks the result.
What to monitor for every client
Before switching anything on, build the inventory. For each client, list every public hostname a customer could land on:
- Main site:
client.comandwww.client.com(they can resolve to different servers) - Revenue pages:
shop.,checkout.,book.,portal. - Campaign and legacy subdomains: last year's launch page, a regional site, the microsite that became permanent
- Client-facing tools:
status.,support.,app.
Next to each hostname, write who owns renewal: host, CDN, platform, your team, or the client. Where the answer is "not sure", you have found your risk.
This inventory is worth doing even before you choose a tool. It is common to find a forgotten subdomain the first time you do it.
How to set up SSL monitoring for client sites in Domain Pilot
Domain Pilot does not issue, renew or deploy certificates. It watches them, independently, alongside the domain registration, DNS and uptime for every client, so one missed setting does not turn into a client call.
1. Connect the registrar accounts your clients use
Agencies rarely have one registrar. Domain Pilot connects to 9 registrars via API: GoDaddy, Namecheap, Cloudflare, Porkbun, IONOS, Hostinger, NameSilo, Epik and Name.com. Connect each account your client domains live in, including client-owned accounts you have access to, and every domain syncs into one dashboard. The registrar connection guides walk through each one.
Nothing is transferred. Domains stay exactly where they are.
2. Turn on SSL monitoring for each client domain
SSL monitoring is included on Starter and higher plans. Domain Pilot checks the live certificate on each domain every day and records the expiry date, days remaining, issuer, subject and serial number.
Work through your inventory from the previous section, not from memory. SSL monitoring runs on each domain you track, so cover subdomains like shop.client.com with uptime monitoring on their HTTPS URLs (step 4) and keep them on your inventory.
3. Route alerts to whoever will fix it
An alert only helps if it reaches the person who can act. Domain Pilot sends SSL alerts by email, Slack and push notification, and you can set preferences per notification type and channel.
For most agencies, the right setup is a shared Slack channel for the dev team plus email to the account lead. Alerts start 30 days before a certificate expires and repeat daily until it is renewed, so there is always time to fix it without a fire drill.
4. Pair SSL monitoring with uptime monitoring
A valid certificate on a site that returns a 500 error is still an outage. Add HTTP/HTTPS uptime monitoring for each client's key pages. You can set the expected status code, expected response text and redirect behaviour, so you know the right page is loading, not just that the server answered.
On Plus, checks run every minute, and each client can get a public status page. That turns monitoring from an internal safety net into something the client can see: proof that you are watching.
5. Keep domain expiry and DNS changes in the same place
An expired domain takes the certificate, the site and the email down with it. A DNS change is the most common reason certificate provisioning silently stops.
Domain Pilot tracks domain expiry with alerts at 90, 60, 30, 14, 7, 3 and 1 day out, and flags DNS changes so you can check them. SSL, uptime, DNS and renewals in one view means one place to look when something breaks.
A monthly SSL routine for agencies
Put 15 minutes on the calendar once a month:
- Add any new client sites and subdomains to the inventory.
- Confirm every hostname has a named renewal owner.
- Check which certificates expire in the next 30 days.
- Confirm alerts still reach the right channel (people leave, Slack channels get archived).
- Review recent DNS changes on client domains.
- After any migration or host change, confirm the live site serves the expected certificate.
The last one matters most. Renewal is not done when a dashboard says so. It is done when the live site serves the new certificate.
When an SSL alert fires
- Identify the hostname and client. Main site, checkout, or a forgotten subdomain?
- Check the certificate details. Expiry date, issuer and serial number tell you which certificate is live.
- Check the renewal owner. Host, CDN, plugin or platform. Did renewal run?
- If it renewed but the old certificate is still live, check the delivery path: proxy, CDN or load balancer.
- Check recent DNS changes. Moved DNS is a common cause of failed provisioning.
- Tell the client after it is fixed. "We caught an expiring certificate on your checkout and renewed it" is a sentence that retains clients.
Frequently asked questions
How often should SSL certificates be checked?
At least daily for production sites. Domain Pilot checks every monitored certificate once a day. With certificate lifetimes heading to 47 days, a monthly manual check is no longer enough.
Does auto-renewal mean I don't need SSL monitoring?
No. Auto-renewal requests the certificate. Monitoring confirms the live site is actually serving it. A renewal can succeed while the live site keeps serving the old certificate.
Do Shopify or Squarespace sites need SSL monitoring?
Those platforms provision and renew SSL for you, so the risk is lower. It is not zero: if the client's DNS stops pointing correctly, provisioning can fail. Monitoring the domain and its DNS catches that.
What is the maximum SSL certificate lifetime in 2026?
200 days for certificates issued from March 15, 2026. It drops to 100 days in March 2027 and 47 days in March 2029.
Can I monitor SSL for client domains that live in the client's own registrar account?
Yes, if you can connect that account. Domain Pilot connects via API to 9 registrars, and domains stay in the client's account.
Hear about it before your client does
Auto-renewal is a good first layer. It is not proof. The agencies that keep clients for years are the ones who find the problem first and mention it as a fix, not an apology.
Domain Pilot puts SSL, uptime, DNS and domain expiry for every client in one dashboard, across 9 registrars, with alerts that reach the person who can act.
Check a client certificate now with the free SSL Expiry Checker, or connect your first registrar and see every client domain in one place.