How to Set Up SSL Monitoring for All Your Client Domains in 30 Minutes

Most agencies put off setting up SSL monitoring because it sounds like a half-day project. It is not. If you have a list of your client domains — even a rough one — you can have monitoring running across your entire portfolio in under 30 minutes. This guide walks through the complete setup from account creation to first client report.

The steps below assume you are starting from zero. If you already have some domains configured, skip to the step that matches where you are.

What You Will Need Before You Start

Getting everything in front of you before you begin makes the setup faster and avoids interruptions:

A list of client domains — primary domains only. Subdomains can be added later. If you manage 15 clients with one primary domain each, you are starting with 15 entries. A spreadsheet or plain text list works fine.
Client contact email addresses — for configuring per-client report delivery. You do not need to be able to send to these addresses during setup; you just need to have them.
Your own alert email — the address that receives internal alerts when something needs attention.
20–30 minutes — the setup is linear and each step is short.

Step 1: Create Your Account and Set Up the First Client (5 minutes)

Go to app.merlonix.com and sign up with your agency email. Merlonix uses magic-link authentication — no password to create or store.

After signing in, you will see the client dashboard. The first thing to do is create a client account for your first client. Click Add Client and fill in:

Client name — the name you use internally. This appears in reports and the dashboard.
Primary contact email — the email address that receives client-facing reports.
Notes — optional, but useful for recording things like "staging domains are excluded" or "contact has low alert tolerance."

Create the client record. You now have your first isolated client account. Everything you add next — domains, alerts, reports — belongs to this client and cannot be confused with another client's data.

Decision point: If you have more than five clients, set up all client records first before adding domains. It is faster to create all the client shells, then add domains to each, than to fully configure one client before moving to the next.

Step 2: Add the Client's Domains (5 minutes)

With the client record open, navigate to Domains and click Add Domain.

Enter the primary domain (for example, clientname.com). Merlonix will automatically:

Monitor the apex domain certificate (clientname.com)
Monitor the www subdomain if a certificate exists (www.clientname.com)
Check DNS records for the apex domain
Check domain expiry against WHOIS data

If the client has additional subdomains that carry their own certificates — a client portal at portal.clientname.com, a campaign microsite at sale.clientname.com, a staging environment — add each as a separate domain entry. Subdomains with separate certificates need separate monitoring entries because they can expire independently.

Repeat for each domain associated with this client. When you are done, you will see a domain list with the current status of each.

What you should see: Within 2–3 minutes of adding a domain, Merlonix has completed its first check. The dashboard will show current SSL validity status, days until expiry, DNS record health, and domain registration expiry. If anything is already in a warning state, it will be flagged immediately.

Step 3: Configure Monitoring Thresholds (5 minutes)

The default SSL expiry threshold is 30 days for warning and 14 days for critical. These defaults are reasonable but agencies often need tighter thresholds for high-stakes clients or looser ones for clients who manage their own renewals.

Navigate to Settings → Monitoring for the client and adjust:

SSL expiry thresholds:

Warning: 30 days (default) — adjust to 45 days for clients with infrequent IT access or complex renewal processes
Critical: 14 days (default) — this triggers the escalation-priority alert

DNS check scope:

A record monitoring is on by default — correct
MX record monitoring — enable for clients where email delivery is part of your scope
CNAME monitoring — useful for clients with CDN-routed domains

Domain registration expiry:

Warning: 60 days (default) — reasonable for most clients
Critical: 30 days — tighten to 45 for clients whose registrar contacts are unreliable

Set these at the client level, not globally, so each client's configuration reflects their actual risk profile.

Step 4: Configure Alert Routing (5 minutes)

Alert routing is what separates a monitoring tool from a portfolio management tool. Every alert in Merlonix is scoped to the client it originated from. Configure where each client's alerts go.

Navigate to Alerts → Channels for the client:

Your internal alert address:

Add your agency email as the primary alert recipient for all alert severities
This is your operational inbox — everything goes here

Client notification (optional):

Some agencies route critical-severity alerts directly to the client's technical contact as well as internally
Some route nothing to the client and handle communication manually
Set this based on your service agreement and the client's technical sophistication

Slack (if your agency uses it):

Merlonix supports Slack webhook delivery per client
A common pattern: all critical alerts to #monitoring-critical, all warning alerts to #monitoring-review

Alert deduplication:

SSL expiry alerts deduplicate by default — you will not receive a new alert every hour for the same expiring certificate. You receive the initial alert and an escalation if the condition is not resolved within the threshold window.

Repeat alert configuration for each client. Client A's SSL alert goes to Client A's channel; Client B's alert stays scoped to Client B. Cross-client alert confusion — the most common operational failure mode with flat monitoring tools — is structurally prevented.

Step 5: Generate Your First Client Report (5 minutes)

Navigate to Reports for the client and click Generate Report.

The report covers:

All monitored domains with current SSL status
Expiry dates and days remaining
DNS record health
Domain registration status
Any alerts raised in the reporting period and their resolution status
Monitoring coverage summary

For a new client, the report will show full monitoring coverage with first-check results. This is also your proof-of-service document: it shows the client what you are monitoring and confirms that monitoring is active.

Download the PDF and review it. This is approximately what your monthly client report will look like. If anything looks off — wrong domain names, missing subdomains, alert thresholds not matching what you configured — correct it now while setup is fresh.

Scheduling reports: Set the report delivery schedule to monthly, timed to arrive a few days before your client billing date. This gives you a review window before the client sees it and a natural billing conversation anchor.

Step 6: Add the Remaining Clients (5 minutes)

Return to the dashboard and repeat steps 1–5 for each remaining client. The time per client drops significantly after the first one because you have already made the configuration decisions. Most agencies find they can configure 10–15 clients in 20 minutes once they know the pattern.

Batch approach for large portfolios:

Create all client records first (name + email only)
Add all domains for all clients
Configure thresholds globally using your standard agency defaults
Override per-client thresholds for exceptions
Configure alert routing per client
Generate and review all first reports in one pass

At 20 clients, this batch approach takes 25–35 minutes total rather than 60+ minutes of sequential setup.

After Setup: What to Do in the First Week

Day 1–2: Review the initial check results across all clients. Any domain already in a warning or critical state needs immediate action — an expiring certificate discovered during setup is one you can fix before the client is affected.

Day 3–5: Review the first monitoring data. Look for unexpected DNS records (a client may have a legacy subdomain you did not know about), misconfigured certificates (incomplete chains are common on self-managed certificates), and domain registrations expiring sooner than expected.

Day 7: Send the first monitoring summary to each client. Even if nothing is wrong, the act of sending a report confirms that monitoring is active and positions it as a service the client is receiving.

Common Setup Mistakes

Adding only the apex domain and ignoring subdomains. The most common SSL incidents in agency portfolios involve subdomain certificates — a staging environment, a client portal, a campaign microsite. Each subdomain with its own certificate needs a separate domain entry.

Using the same alert email for all clients. If your internal alert address receives all alerts from all clients without client scoping, you will start building filters to manage the noise. This is exactly the problem Merlonix's per-client alert routing solves — use it.

Skipping the threshold review. Default thresholds are calibrated for the average site. A client with a complex certificate renewal process that involves a third-party IT team needs 45-day warning lead time, not 30. Take the five minutes during setup to match thresholds to the client's renewal reality.

Not generating the first report. The first report is both a quality check on your setup and the baseline document for your monitoring retainer. Generate it before you consider setup complete.

What Merlonix Monitors

SSL monitoring covers:

Certificate validity and expiry (apex domain and each subdomain)
Certificate chain completeness
Key algorithm and signature algorithm (for downgrade detection)
Subject Alternative Names (SAN coverage)

DNS monitoring covers:

A record resolution
MX record resolution (when enabled)
CNAME chain resolution
Propagation anomalies

Domain registration covers:

Registrar-reported expiry date
WHOIS data consistency

Vendor monitoring (available after initial setup) covers:

Third-party services embedded in client sites (CDNs, analytics, payment processors, form tools)
Independent status checks against vendor status pages