SSL Certificate Monitoring for Agencies: How to Stop Client Outages Before They Happen
SSL certificate expiry is the most predictable disaster in digital marketing. The certificate has an expiry date. You know when it is going to expire. You know exactly what happens when it does — every visitor sees a red "Your connection is not private" warning and your client's site becomes effectively inaccessible. And yet agencies get caught by this repeatedly.
This guide explains why SSL expiry keeps happening in agency environments and what monitoring setup actually prevents it.
Why SSL Expiry Keeps Catching Agencies
The obvious answer is "nobody remembered to renew it." But that obscures the real problem, which is structural.
Client sites sit outside the agency's direct control. The certificate may be managed by the client's hosting provider, their IT team, their previous agency, or an auto-renewal tool that stopped working when the credit card on file expired. The agency has no visibility into which of these is true for any given client site.
Staff turnover and client transitions create gaps. When a client onboards, they share credentials and account access. When a client offboards, that institutional knowledge often walks out the door. The new team inherits a list of clients but not a complete map of who controls what SSL certificate.
Auto-renewal is not the same as monitoring. Let's Encrypt will auto-renew if the ACME challenge succeeds. The challenge fails silently if DNS records change, if a WAF blocks the challenge path, or if the hosting environment shifts. The certificate expires. Nobody knew.
Alerts from hosting providers are unreliable. Some providers send expiry warnings to a mailbox associated with the account, not the currently responsible party. That warning goes to a previous employee, a shared inbox nobody checks, or an email address that stopped forwarding.
What SSL Certificate Monitoring Actually Covers
Monitoring an SSL certificate means more than checking whether it is expired. A complete SSL monitoring implementation tracks:
Days until expiry. The most obvious metric, but the alert threshold matters. Thirty days is the minimum viable lead time — enough for one billing cycle, one slow client, and one unexpected DNS propagation delay. Sixty days is safer for agencies managing many clients with complex approval processes.
Issuer changes. If a certificate renews and the new issuer is different from the previous one, that is worth investigating. It could mean the auto-renewal chain switched providers (benign), or it could mean someone issued a certificate for your client's domain using a different account (not benign).
Subject Alternative Name changes. SAN lists define which subdomains the
certificate covers. If a client's certificate previously covered www, app,
and api but the renewal only covers www, the subdomains will throw errors
the next time a visitor hits them.
Key algorithm and size. RSA 2048-bit is the current floor. Anything weaker is a finding worth flagging to the client.
Signature algorithm. SHA-1 certificates have been distrusted by all major browsers. If a certificate is still using SHA-1, that is an urgent remediation.
The Alert Threshold Problem
Most SSL monitoring tools send one alert at 30 days. That is not enough for an agency environment.
Consider the realistic workflow: the alert arrives, someone notes it, forwards it to the client contact, waits for a response, the client contacts their hosting provider, the provider has a support queue, there is back-and-forth about whether to renew or change providers, the client wants to move to a new hosting setup anyway while they are at it. Thirty days evaporates.
The alert schedule that actually works in agency environments:
| Days Until Expiry | Alert Type | Action |
|---|---|---|
| 60 days | Warning | Assign to account manager, notify client |
| 30 days | Urgent | Escalate internally, confirm client has taken action |
| 14 days | Critical | Direct intervention, offer to manage renewal |
| 7 days | Incident-level | Treat as active incident, all hands |
| 0 days (expired) | Outage | Emergency response |
Monitoring Across a Client Portfolio
Monitoring one site is a solved problem — almost every hosting provider includes basic SSL expiry notifications. The hard problem for agencies is monitoring dozens or hundreds of client sites with a single view and reliable alerting.
The workflow that emerges at scale:
Centralised asset inventory. Every client domain is registered in one place with metadata — client name, hosting provider, renewal responsibility (client or agency), auto-renewal status, and the expiry date. Without this, the monitoring system cannot alert the right person with the right context.
Aggregated status view. When you need to answer "which client certificates are expiring in the next 30 days?" in under 30 seconds, you need a dashboard, not a pile of individual hosting logins.
Routing alerts to account managers. A certificate expiry alert going to a generic monitoring inbox is almost as bad as no alert. The person who receives the alert needs to be the person who owns the client relationship and can take action immediately.
Automated evidence capture. When a client disputes whether their site was protected, you need a timestamped record of what the certificate state was on any given date — not just the current state.
Common SSL Monitoring Mistakes
Monitoring the wrong hostname. Many agency sites redirect example.com to
www.example.com. If you only monitor www.example.com, the apex domain
certificate can expire without triggering an alert. Monitor both.
Ignoring staging and preview environments. Clients often share preview URLs publicly. A staging site with an expired certificate erodes confidence even when the production site is fine.
No verification after renewal. Confirming that renewal was completed requires actually connecting to the site and reading the new expiry date, not just checking that the renewal task was "done" in the hosting panel. Renewal tasks fail silently.
Single alert channel. If the only alert channel is email and the account manager is on leave, the alert waits. Multi-channel alerting — email plus Slack plus a backup — is not paranoia, it is redundancy for a high-stakes notification.
Setting Up SSL Monitoring for Your Agency
The minimum viable setup for an agency managing more than five client sites:
- Inventory all client domains — apex and www variants, plus any branded subdomains (app, api, mail, staging).
- Record the renewal responsibility — who actually has access to renew each certificate? Is it the client, the hosting provider, or the agency?
- Set monitoring with 60-day and 30-day alert thresholds — not just 30 days.
- Route alerts to named account managers — not a shared inbox.
- Verify the new certificate after every renewal — confirm the expiry date has advanced and the issuer is correct.
- Document the renewal process in the client's account file — so any team member can execute the renewal without tribal knowledge.
Merlonix monitors SSL certificates across your full client portfolio, alerts the right person at the right threshold, and captures a timestamped record of every certificate state. Start monitoring →
→ Complete guide: The Complete Guide to Digital Certificate Verification for Marketing Agencies