How to Set Up SSL Monitoring for Your Agency: A Step-by-Step Guide

SSL monitoring for an individual project is straightforward: add the domain, set an expiry alert, and move on. SSL monitoring for an agency managing 20–50 client domains across Shopify, Webflow, Netlify, WordPress, and Vercel is a different problem. The tool configuration is the easy part. What takes thought is the structure: how to organize clients, which domains to include, what thresholds to set, and how to route alerts so the right person sees the right issue without alert fatigue.

This guide walks through setting up agency-grade SSL monitoring from scratch — covering the decisions that trip agencies up, not just the click-by-click steps.

Step 1: Define What You Are Monitoring

Before configuring any monitoring tool, list what needs to be covered. For agencies, this is almost always larger than expected.

What to include per client:

Production domain — the primary client domain (clientdomain.com, www.clientdomain.com)
Staging and preview subdomains — staging.clientdomain.com, preview.clientdomain.com, or equivalent
API subdomains — api.clientdomain.com, services.clientdomain.com, or any custom subdomain used for backend API access
Transactional email subdomains — if the client uses a subdomain for sending email (mail.clientdomain.com), this is rarely SSL-monitored but can affect email delivery
Platform-specific subdomains — Shopify checkout subdomain, Webflow form submission endpoint, or any platform feature subdomain

What agencies commonly miss:

The most common omission is staging and preview subdomains. Agencies often set up production monitoring and stop there. Staging subdomains break more frequently than production domains — they see more DNS changes, they are on shorter certificate renewal cycles, and they are configured by developers rather than operations staff. A broken staging subdomain blocks client UAT and sign-off cycles, which directly affects project velocity.

The second most common omission is API subdomains. These are treated as backend infrastructure and monitored separately, or not monitored at all. When an API subdomain certificate expires, the client symptom is "the site looks fine but nothing works" — which is harder to diagnose than an outright site outage.

Step 2: Organize Monitoring by Client, Not by Domain

The natural impulse when setting up monitoring is to add domains to a flat list. For an agency managing 30 clients with an average of 3 domains each — 90+ domains — a flat list creates several operational problems:

Alert routing: When client A's staging subdomain alerts, who gets notified? The alert goes to whoever configured the monitor, not necessarily the account manager for client A.
Client reporting: Pulling an SSL health summary for a client quarterly requires filtering through a flat list rather than pulling a per-client view.
Onboarding efficiency: Adding a new client means configuring each domain individually with its own alert contacts, rather than adding a client account and inheriting the defaults.

Organize monitoring by client account from the start:

Create a client group or account for each client
Set the alert contact (email, Slack channel, or account manager) at the client level
Add all domains for that client under the client account
Set the check interval and expiry threshold at the client level — individual domains inherit the defaults

This structure means adding a new client takes two minutes, not 20. It also means client reporting is a one-click export rather than a manual filter operation.

Step 3: Set Alert Thresholds

SSL certificate expiry threshold:

30 days is the minimum useful threshold for agency monitoring. This gives enough time to:

Identify that the renewal is needed
Check that the CNAME is intact before initiating renewal (critical — see the SSL renewal checklist)
Initiate renewal with the hosting platform
Verify the renewed certificate is serving correctly

For agencies where SSL renewals require client action (clients who manage their own registrars or hosting), 45–60 days provides buffer for client scheduling and response time.

Domain registration expiry threshold:

60 days for initial warning. 30 days for escalation. Domain registration renewal requires client action — a payment to the registrar — and clients often delay. 60 days provides enough time for the warning to go out, the client to acknowledge it, and the renewal to be completed before the 30-day escalation window.

DNS check interval:

5 minutes for production domains. 10–15 minutes for staging domains. The check interval determines how quickly you detect a CNAME break or DNS change. A 5-minute interval catches a client registrar migration within minutes of the DNS change propagating — while the existing SSL certificate is still valid and the fix is a DNS record update rather than an emergency SSL reprovision.

Step 4: Configure CNAME Integrity Monitoring

Standard SSL expiry monitoring — checking whether the certificate is still valid and how many days until it expires — is a necessary baseline. It is not sufficient for agency use.

The failure mode that catches agencies off guard is not certificate expiry. It is CNAME drift: the underlying DNS record that points the client's domain at the hosting platform changes or disappears, and the SSL certificate cannot be renewed at the next cycle because the ACME validation fails against the broken DNS.

CNAME integrity monitoring checks whether the CNAME record is still pointing at the expected target, on every monitoring interval, using multiple independent DNS resolvers.

Configure CNAME monitoring for every custom domain managed through a hosted platform:

Platform	Expected CNAME target
Netlify	`[site-name].netlify.app`
Vercel	`cname.vercel-dns.com`
Shopify	`shops.myshopify.com`
Webflow	`proxy-ssl.webflow.com`
Cloudflare Pages	`[project].pages.dev`
GitHub Pages	`[username].github.io`

Document the expected CNAME target for each client domain at setup. When the CNAME changes without a corresponding hosting platform migration, the monitoring fires immediately.

Step 5: Set Up Alert Routing

The most common agency SSL monitoring failure is not the tool — it is the routing. Alerts go to a generic email inbox that no one watches, or to the developer who set up the monitor and has since left the company.

Set up alert routing so that:

Production domain alerts go to the account manager for that client and the agency's technical lead. The account manager needs to know because client communication may be required. The technical lead needs to know because remediation may be required.

Staging domain alerts go to the project manager for the active project with that client. A staging SSL alert is a project delivery risk, not a production incident.

API subdomain alerts go to the back-end or DevOps lead. An API subdomain alert is a technical issue requiring backend investigation.

Domain registration expiry alerts go to the account manager. Registrar renewals require client payment and authorization — the account manager handles the client relationship.

Review alert routing quarterly. People change roles, clients get reassigned, and agencies hire and lose staff. A quarterly routing review takes 20 minutes and prevents alerts from going to inboxes that nobody monitors.

Step 6: Test the Monitoring Setup

After configuring monitoring for a new client, verify it is working before considering setup complete:

Confirm all domains appear in the monitoring dashboard — including staging and API subdomains
Check that the first monitoring run has completed — most tools show last-checked timestamps
Verify the CNAME target matches the expected value — confirm the monitoring tool is reading the correct CNAME, not a cached or stale value
Trigger a test alert — send a test notification to confirm the alert routing is working and reaching the correct recipients
Review the SSL expiry date — confirm it matches what the platform reports

This takes 10 minutes per client at setup and prevents discovering monitoring gaps during an actual incident.

Step 7: Establish a Monthly Review Cadence

SSL monitoring is not set-and-forget. Monthly reviews catch:

Clients whose domains are approaching expiry thresholds — renewals that need to be initiated
CNAME changes that fired alerts — investigate whether the change was intentional (platform migration) or unintentional (registrar error)
New subdomains added since last review — staging environments, API gateways, or marketing campaign subdomains that were not in the original configuration
Alert routing that has gone stale — contacts who have changed roles or left the company

The monthly review complements continuous monitoring — the monitoring catches acute failures, the review catches gradual drift and configuration gaps.

Common Setup Mistakes

Mistake 1: Monitoring www but not the apex domain The apex domain and www subdomain have different certificate configurations on some platforms. Monitor both.

Mistake 2: Setting expiry thresholds too low A 7-day expiry alert leaves no time for CNAME verification before renewal, platform provisioning delays, or client-side delays. 30 days minimum, 45–60 days for client-managed registrars.

Mistake 3: Using a single alert email address Alerts sent to a generic inbox get lost in volume. Route to specific people with specific roles relative to each client.

Mistake 4: Not documenting expected CNAME targets Without a documented baseline, you cannot tell whether a CNAME change is intentional or a break. Document the expected target at setup.

Mistake 5: Ignoring staging and preview subdomains Staging subdomains break more often than production and cause direct project delays. They are not optional to monitor.

Merlonix is designed for agency SSL monitoring with client account organization, CNAME integrity checks, and per-client alert routing built in. Start a free 14-day trial — no credit card required.