Agency SSL Monitoring Checklist: 15 Checks Every Web Agency Needs

Most web agencies start monitoring because something breaks. A client's SSL certificate expires, a site goes offline, and the call comes in at 9pm. After that incident, monitoring gets added to the stack — and then the next incident reveals a gap in the monitoring setup.

This checklist is for agencies who want to get the monitoring setup right before the next incident. It covers the 15 SSL and DNS checks that every web agency managing a client portfolio should have in place, organized by failure type.

Not every check applies to every client. A static site on a single domain needs fewer checks than a Shopify Plus store with a headless frontend, a checkout subdomain, and a staging environment. Use this as a gap analysis — identify what you currently have, identify what you are missing, and prioritize what to add.

Certificate Validity Checks

1. Full certificate chain validation (not just expiry date)

Most monitoring tools check when a certificate expires. That is necessary but not sufficient. A certificate can be valid and unexpired but still cause a browser security error if the intermediate certificate chain is incomplete or misconfigured.

Full chain validation checks that:

The leaf certificate (for the specific domain) is valid
Each intermediate certificate in the chain is correctly ordered
The chain terminates at a trusted root CA
No certificate in the chain has been revoked

A certificate with a broken chain fails for every browser visitor regardless of expiry date. Chain validation failures often appear after a CDN configuration change or a certificate reissuance that pulls a different intermediate from the CA.

Check: Full chain validation per domain, not just expiry date.

2. SSL certificate expiry with 30-day lead time

Standard SSL expiry monitoring fires when a certificate is 14 days from expiry. For most agency clients, 14 days is not enough lead time:

If the failure requires fixing a CAA record conflict, the client's IT team needs time to implement the change and verify it propagated
If the failure requires client cooperation (updating nameservers, recreating DNS records), client communication takes time
If the managed hosting platform's auto-renewal is broken, identifying and fixing the root cause takes time

Check: SSL expiry alert firing 30 days before expiry, not 14 days.

3. SAN (Subject Alternative Name) coverage for all subdomains

A wildcard certificate (*.clientdomain.com) covers all first-level subdomains but does not cover the apex domain (clientdomain.com) or second-level subdomains (staging.app.clientdomain.com). An SAN certificate covers the specific domains listed in the certificate's SAN field.

When a new subdomain is added to a client site without being added to the existing certificate's SAN list, that subdomain has no valid certificate. The subdomain appears to work internally (the server responds) but browsers reject the connection.

Check: Verify that every active subdomain in the client's DNS is covered by a certificate with appropriate SAN entries.

4. Certificate issuer and authority verification

Certificates are issued by Certificate Authorities (CAs). When an unexpected CA issues a certificate for a client domain — which can happen if someone provisions an unauthorized certificate, or if a CDN or managed hosting platform uses a different CA than expected — it may indicate a misconfiguration or, in rare cases, a security issue.

More practically: if your monitoring tracks the expected issuer and the issuer changes unexpectedly after a CDN configuration change, that is an early signal to investigate whether the change was intentional.

Check: Track certificate issuer and flag changes from the expected CA.

DNS Integrity Checks

5. CNAME record integrity for platform delegations

Agencies managing clients on platforms that use CNAME delegation (Shopify, Kajabi, Webflow, Framer, managed WordPress, Bubble) need to verify that the CNAME records pointing client domains to the hosting platform are correctly configured and pointing to the right target.

CNAME integrity breaks most commonly after:

Client nameserver migrations (moving to Cloudflare, switching registrars, consolidating DNS management)
Platform CDN changes that update the expected CNAME target
Partial DNS migrations where some subdomains are recreated and others are missed

Check: CNAME target verification for every platform delegation, using multiple independent resolvers (not just the local resolver).

6. Multi-resolver DNS verification

DNS changes propagate globally over time. A CNAME that looks correct when queried from your local resolver may still be pointing to the old target when queried from resolvers in other regions. This matters because:

Your monitoring fires "resolved" when your local resolver sees the new CNAME
Visitors in other regions see the old CNAME for several more hours
If the old CNAME target has already been decommissioned, those visitors get a DNS failure

Check: DNS verification using at least three geographically distributed independent resolvers on every check interval.

7. A record monitoring for hosting IP changes

Some clients use A records (direct IP addresses) rather than CNAME delegation for their hosting. When the hosting IP changes — after a server migration, a CDN provider change, or a DDoS mitigation service being added — the A record must be updated.

Unexpected A record changes can indicate:

A DNS configuration error (wrong IP entered)
A DNS hijacking event (rare but real for high-value domains)
A hosting migration that was not communicated to the agency

Check: A record change detection with alerts firing on any unexpected IP change.

8. MX record monitoring for email-hosting combinations

Agencies that also manage client email or whose retainer includes DNS zone management need to monitor MX records. An MX record change that routes email to the wrong mail server can disable client email entirely — and email-related incidents are often more urgent to clients than site performance issues.

Check: MX record change detection for any client whose DNS zone is agency-managed.

Domain Registration Checks

9. Domain expiry monitoring with 30-day lead time

Domain registration expiry is entirely separate from SSL certificate expiry and hosting platform health. When a domain expires, everything on that domain goes offline — the site, the email, the API endpoints — regardless of how well everything else is configured.

Domain expiry is a client-side responsibility in most agency relationships: the client owns the domain registration and manages renewal. Agencies rarely have visibility into the registrar renewal status unless they monitor domain expiry directly.

Check: Domain expiry monitoring for every client domain with alerts firing 30 days before expiry — giving enough lead time to contact the client and confirm renewal before any DNS failure starts.

10. Domain registrar lock status

Domains can be transferred away from the current registrar if the domain lock is disabled. Most registrars lock domains by default, but the lock can be disabled intentionally (before a planned transfer) or unintentionally. A domain whose registrar lock is disabled is vulnerable to unauthorized transfer.

This is a lower-priority check for most agencies but relevant for clients in competitive industries or with high-value domain names.

Check: Registrar lock status for high-value client domains.

Environment Coverage Checks

11. Staging environment SSL and DNS

Staging environments are lower severity than production but need monitoring coverage. A staging SSL failure that goes unnoticed:

Blocks the development team from testing
Prevents clients from reviewing work before launch
May indicate a misconfiguration that will affect production during the next deployment

Check: SSL chain validation and CNAME integrity for every staging subdomain, with low-urgency alert routing (email rather than Slack/PagerDuty).

12. Preview and review app URL coverage

Agencies using preview deployment systems (Vercel preview deployments, Netlify deploy previews, or custom staging pipelines) that generate dynamic URLs for each pull request or code branch may have preview URLs that are not individually monitored. At minimum, the base staging subdomain and any persistent review environments should have the same SSL coverage as production.

Check: Persistent review environment URLs covered by SSL monitoring.

13. API subdomain and endpoint SSL

Clients with APIs, webhooks, or third-party integrations exposed via subdomains (api.clientdomain.com, webhooks.clientdomain.com, integration.clientdomain.com) need SSL monitoring for those subdomains independently. An expired certificate on an API subdomain can break integrations that do not surface obviously as a site outage.

Check: API and webhook subdomains included in SSL monitoring coverage.

Platform and Vendor Checks

14. Vendor platform status monitoring

Agencies managing clients on third-party platforms (Shopify, Kajabi, HubSpot, Stripe, Mailchimp) lose time to platform outage investigation. When a Shopify incident degrades checkout across all client stores simultaneously, the agency's first response without vendor monitoring is to investigate client configurations — wasting investigation time on a problem they cannot fix.

Vendor status monitoring correlates platform incident events with client-side symptoms, telling the agency immediately whether a client issue is likely platform-related or client-specific.

Check: Vendor status monitoring for every third-party platform used across the client portfolio.

15. CAA record conflict detection

CAA DNS records specify which Certificate Authorities are permitted to issue certificates for a domain. A client's IT team adding a restrictive CAA record that excludes Let's Encrypt can silently break managed hosting platform SSL renewal — the agency will not know until the existing certificate expires and renewal fails.

Check: CAA record monitoring for client domains where managed hosting platforms handle certificate renewal automatically.

How to Use This Checklist

Run through this list for each client in your portfolio. For each check, mark it as:

In place: You have monitoring that covers this
Partial: You have some coverage but not complete (e.g., you monitor production but not staging)
Missing: No monitoring in place for this check

Start with the items marked Missing that fall into the Certificate Validity and Domain Registration categories — those are the failure modes with the highest client-impact severity and no platform backstop.

How Merlonix Covers These Checks

Merlonix covers all 15 checks for agency client portfolios. Full certificate chain validation, multi-resolver DNS verification, CNAME integrity monitoring, domain expiry tracking, and vendor status monitoring are all included without per-domain configuration.

Adding a client domain takes under two minutes. Start a 14-day free trial and run the checklist against your first client.