An expired SSL certificate is one of the most embarrassing things that can happen to a digital agency. The client’s site goes red in Chrome, visitors get a security warning, and whoever notices it first — usually the client, occasionally their own customer — sends you a panicked message at 7am on a Tuesday. The renewal would have taken ten minutes. The damage to trust takes considerably longer to repair.
What makes it worse is that SSL expiry is entirely predictable. Unlike a server outage or a hacked plugin, a certificate expiring on a specific date is known weeks or months in advance. There’s no excuse for it happening — yet it happens constantly, at agencies of every size. The reason is almost never negligence; it’s process failure. Certificates are spread across multiple clients, multiple hosting environments, and multiple registrars, and the only people tracking them are whoever set them up, who may or may not still work at the agency.
This guide sets out how to build a reliable SSL certificate management process for an agency portfolio — from understanding why certificates lapse to building automated tracking that keeps you in front of every expiry date across every client.
Why SSL Certificates “Unexpectedly” Expire
When you dig into why an agency missed a renewal, the cause is almost always the same: the certificate was set up once, the renewal notification went to an email address nobody monitors, and the auto-renewal either wasn’t configured or silently failed. Let’s unpack each of those.
SSL certificates from commercial certificate authorities — DigiCert, Sectigo, GlobalSign — are typically issued for one or two years. When you purchase one, the CA sends renewal reminders to the contact address on the account. If that address was a previous employee’s inbox, a generic inbox that nobody watches, or a personal email the developer used when setting up the client account three years ago, those reminders land in a void. The certificate expires on schedule; nobody knew it was coming.
Let’s Encrypt certificates — now used on the majority of new sites — are different. They’re free and valid for 90 days, designed to be renewed automatically via Certbot or similar tooling. Auto-renewal usually works. But “usually” is the problem at scale. A Certbot job that renews fine on 47 servers can silently fail on the 48th because of a permissions change, a lapsed cron job, or a web root that moved during a migration. The site ticks along on HTTP/2, serving pages fine, and nobody notices until the certificate expires and browsers start blocking traffic.
The third failure mode is less technical: organisational change. A client moves their hosting, migrates from one platform to another, or takes a domain in-house. The certificate that was set up under the agency’s management quietly becomes someone else’s problem — except nobody told anyone, and the agency is still listed as the technical contact. When it expires, the client calls you.
What SSL Monitoring Should Actually Cover
Before building a system, it’s worth being precise about what you’re trying to monitor. “SSL monitoring” is sometimes used narrowly to mean just checking whether a certificate is present and valid. For an agency managing client sites, the scope needs to be broader.
Expiry date tracking. The core requirement: know when every certificate in your portfolio expires, and get a warning far enough in advance to act without rushing. Thirty days is a sensible minimum alert window. Fourteen days is your second alert. Seven days should be treated as urgent. Anything under 72 hours is a crisis that was allowed to develop through process failure.
Certificate validity. A certificate can be current — not yet expired — but still invalid. Common causes include domain mismatch (the certificate was issued for www.example.com but the site is now served at example.com without the www), a self-signed certificate that was a temporary measure and never replaced, or a certificate issued by a CA that’s been revoked or distrusted by browser vendors. Validity checks catch problems that expiry monitoring alone misses.
Certificate chain completeness. SSL certificates don’t stand alone; they’re validated through a chain of trust from the site certificate up to a root CA. If an intermediate certificate is missing from the server configuration — something that happens routinely when a certificate is manually installed — some browsers and clients will refuse the connection even though the end-entity certificate is valid and current. Certificate chain checks are the kind of thing developers often skip when they’re in a hurry.
Protocol and cipher suite health. This is more advanced, but for agencies serving regulated clients — finance, healthcare, e-commerce with PCI-DSS obligations — knowing whether a site still supports deprecated protocols like TLS 1.0 or weak cipher suites is commercially important. Clients’ security auditors will find these; better that you find them first.
Manual Approaches and Their Limits
Before looking at automated monitoring, it’s worth acknowledging why manual approaches fail — because most agencies start with them and genuinely try to make them work.
The spreadsheet approach: maintain a shared sheet with client name, domain, certificate provider, expiry date, and a column for renewal status. Set calendar reminders for 60 and 30 days before each expiry. This works for five clients. At twenty clients it’s maintenance overhead. At fifty clients it’s a full-time job, and the sheet is perpetually stale because updating it requires discipline that’s hard to sustain across a team.
The hosting panel approach: log into each hosting provider’s control panel periodically and check certificate status. Some panels surface expiry dates prominently; many don’t. This approach also only covers sites where you have hosting access — which may not be all your clients, and certainly not the ones who manage their own servers.
The problem with manual approaches isn’t that they fail immediately — it’s that they degrade over time. Someone leaves, the spreadsheet falls behind, a new client gets added but the SSL tab doesn’t get updated. The process that worked when you had eight clients starts leaking when you have twenty-five. The certificates that expire are almost always the ones that slipped through a gap in the process, not the ones that were well-managed.
Manual SSL tracking doesn’t fail — it degrades. By the time you notice the gaps, a certificate has already expired.
Building Automated SSL Tracking Across Your Portfolio
Automated SSL monitoring checks the TLS handshake on each domain at regular intervals — typically every few hours — and extracts the certificate’s expiry date, issuer, subject, and chain details. When something changes or a threshold is crossed, it triggers an alert. The mechanics are straightforward; the value is in how the monitoring integrates with your existing workflow.
There are broadly three ways agencies approach this:
Standalone SSL monitoring tools
Tools like SSL Shopper’s monitoring service, Keychest, or HetrixTools offer dedicated SSL certificate tracking. You add domains, configure alert thresholds, and receive email or webhook notifications when certificates approach expiry or fail validation. These work well as single-purpose tools. The limitation is that SSL monitoring sits in a separate dashboard from everything else you manage, so the workflow is: receive alert in email → look up which client it belongs to in CRM → take action. Each step adds friction.
Uptime and site monitoring platforms
Broader uptime monitoring tools — UptimeRobot, Better Uptime, Site24x7 — include SSL checks alongside HTTP uptime monitoring. This is a sensible combination, since a site that’s down and a site with an expired certificate are both things you want to know about in the same place. You’re still maintaining a separate monitoring dashboard, but at least it covers multiple site health dimensions.
Agency management platforms with built-in monitoring
The most efficient approach for agencies is to have SSL monitoring embedded directly in the tool you use to manage client relationships. Marque CRM’s site monitoring module checks uptime, SSL certificate validity and expiry, and WordPress plugin status for every site associated with a client record. When a certificate is approaching expiry — or has already lapsed — it appears as a flag on the client’s site record, and the relevant team member receives an alert through the same notification system as their other tasks and updates. There’s no separate dashboard to maintain and no manual connection between a monitoring alert and the client it relates to.
The practical difference between approach one and approach three: with a standalone tool, an SSL alert tells you “example.com expires in 14 days.” With an integrated approach, that same alert is surfaced in the context of the client — you can see who the account manager is, whether there’s an active retainer covering hosting management, and whether there’s an existing support ticket related to the renewal. The information that allows you to act is right there.
A Practical Renewal Workflow for Agency Teams
Monitoring tells you when a certificate needs attention. You still need a defined workflow for what happens next, because “someone will deal with it” is how renewals get missed despite having alerts in place.
A workable renewal workflow looks like this:
60 days out: Certificate added to the renewal queue. Account manager notified to check whether the client is on a hosting management retainer (in which case renewal is within scope), or whether the client manages their own hosting (in which case they need to be notified). For Let’s Encrypt sites, verify that auto-renewal is configured and last ran successfully.
30 days out: If renewal is within your scope, the task is assigned to a developer with a due date two weeks out. If the client manages their own hosting, send a proactive notification to the client — this positions your agency as attentive and technically on top of things, even when you’re not the one doing the renewal. It also protects you: if the client ignores your warning and the certificate expires, you have a timestamped communication showing you flagged it.
14 days out: Chase and confirm renewal has been completed or is in progress. For commercial certificates requiring manual purchase, confirm the new certificate has been ordered and is ready to install.
7 days out: If still unresolved, escalate. At this point it becomes urgent. Any blocker — client not responding, payment issue with the CA, technical problem on the server — needs to be resolved immediately.
The key to this workflow is that it assigns ownership at each stage, rather than leaving renewal in a shared “someone needs to do this” category. SSL renewals that slip through are almost always in a grey zone of ownership. Being explicit about who is responsible at each threshold prevents that.
Turning SSL Management Into a Retainer Line Item
Once you have robust SSL monitoring in place, there’s a commercial opportunity worth considering: positioning proactive site security management as a defined service rather than something you do silently as part of the relationship.
Many agencies already include hosting management in their retainers but describe it vaguely — “technical support and maintenance” is a common phrase that doesn’t tell the client what they’re actually getting. Reframing this as a specific set of deliverables — SSL certificate monitoring and renewal, uptime monitoring, WordPress core and plugin updates, security scanning — gives the service concreteness that makes it easier to price and easier for clients to value.
A light monthly maintenance retainer that includes SSL management and uptime monitoring, priced somewhere between £75 and £150 per site per month, is a straightforward sell to clients who care about reliability. The cost to you of providing it, once you have automated monitoring in place, is minimal. You’re essentially charging for the infrastructure and accountability, not the time — because the time is near-zero until something actually needs renewing or fixing.
This also changes the dynamic when something does go wrong. If a client is on a maintenance retainer, a certificate expiring (which shouldn’t happen) is covered; you fix it and report on it. If they’re not on a retainer, the same event is your liability in their eyes. Formalising the service clarifies commercial responsibility for both parties. See our guide on retainers versus project pricing for more on structuring recurring revenue around services like this.
SSL Management Beyond Expiry: The Bigger Picture
SSL certificate management is often treated as a narrow, technical task — renew the certificate before it expires, done. But for agencies managing client sites at scale, it’s part of a broader site health posture that covers uptime, performance, plugin security, and security headers.
Consider what a comprehensive site health check actually encompasses. An SSL certificate can be valid and current while the site simultaneously has a WordPress installation running 30 versions behind, three plugins with known vulnerabilities, and HTTP security headers that would fail any basic penetration test. The certificate is fine; the site is not secure. Treating SSL in isolation misses the bigger picture.
This is why agencies serious about technical account management tend to use monitoring that covers multiple health dimensions in one place — uptime, SSL, CMS version, plugin status, performance, and security headers — rather than stitching together five separate tools. The signal-to-noise ratio is better, the context is richer, and the overhead of managing the tooling is lower. Marque CRM’s site monitoring is designed around exactly this model: a single view of each client’s site health that surfaces SSL status alongside uptime, WordPress plugin vulnerabilities, and other signals, all tied to the client record in your CRM.
For agencies who want to go deeper, our article on building an agency metrics dashboard covers how to surface site health data alongside your business metrics so nothing falls through the cracks. And if you’re thinking about how to systematically monitor client relationships beyond just their sites, client health scores are a natural complement — combining technical site signals with relationship signals into a single indicator of account health.
The Simple Standard: No Certificate Should Ever Surprise You
SSL certificate management isn’t complicated. Every certificate has an expiry date; every expiry date is knowable in advance; therefore every certificate can be renewed before it expires. The technology is not the hard part. The hard part is building a process that remains reliable as your client portfolio grows, as staff change, and as hosting environments evolve.
The standard to aim for is simple: no SSL expiry should ever come as a surprise. If a certificate expires on a client site and you only find out because the client called you, your process has failed. The monitoring exists, the tooling exists, and the workflow is straightforward. The only question is whether you’ve put the infrastructure in place to make it systematic.
Agencies that get this right don’t do it by being more diligent — they do it by removing diligence from the equation. Automated monitoring, integrated alerts, assigned ownership, and a retainer model that makes the service explicit. Once the system is in place, SSL renewals become a routine task that almost never requires urgent attention. That’s the goal.