Client Website Monitoring for Agencies: What You Need to Track (and What You Can Skip)
There is a version of client website monitoring that agencies set up once and forget about until a client calls. There is another version that creates a constant stream of low-signal alerts that trains the team to ignore the inbox. Neither is useful.
This guide is about the third version: monitoring that surfaces real problems early and routes them to the person who can act on them, without flooding anyone with noise.
The Agency Monitoring Problem Is Not Technical
Most monitoring tools work fine. The problem is that they are designed for a single operator monitoring their own infrastructure — where every alert is relevant, every decision is yours to make, and the context is all in your head.
Agency monitoring is different:
- You are monitoring infrastructure you do not control
- Multiple team members are responsible for different clients
- The person who receives the alert may not be the person who can fix it
- Clients need to be notified, but only when there is something actionable to say
- You need to demonstrate that monitoring exists and is effective, not just that it is configured
The monitoring design question for agencies is not "what tools do we use?" It is "what is the workflow from alert to resolution, for every type of problem we might encounter?"
What to Actually Monitor for Client Sites
SSL certificate status
SSL certificate expiry is responsible for a disproportionate share of client site incidents at agencies. The certificate is not renewed, the site throws a browser security warning, and the client calls the agency.
Monitor with alert thresholds at 60 days and 30 days — not just 30 days. The 60-day alert gives you enough lead time to coordinate with clients who have complex renewal processes or hosting situations the agency does not directly control.
DNS record integrity
DNS changes break client sites in ways that are slow to diagnose without a record of what the correct state looked like before the change. An A record that changes to a wrong IP, an MX record that disappears, a CNAME that starts pointing to a deprecated endpoint — these produce symptoms that look like hosting failures but are actually DNS failures.
DNS monitoring gives you a timestamped record of what every DNS record looked like before and after a change. That is the most valuable thing in the first ten minutes of a client site incident.
Upstream vendor status
This is the category most agency monitoring setups miss entirely. Many client sites depend on third-party platforms: Stripe for payments, Cloudflare for CDN and DDoS protection, Shopify for e-commerce, Anthropic or OpenAI for AI features, GitHub for deployments, Vercel or Netlify for hosting.
When any of these platforms has an outage, client sites that depend on them are affected — even if the client's own infrastructure is fine. Without vendor status monitoring, agencies diagnose these as internal problems and burn time on investigations that resolve when the vendor's incident resolves.
Monitoring vendor status pages centrally means you know immediately whether a client issue is internal or vendor-caused, and you can communicate accurately to clients during incidents.
What you can deprioritise
Page load performance — important for SEO, but not time-critical enough to require round-the-clock monitoring that creates alerts outside business hours. Weekly or monthly performance reports are appropriate; 24/7 performance alerts are not.
Content monitoring — watching for changes to specific page content is a legitimate use case, but it generates significant noise (CMS previews, A/B tests, personalisation) and requires careful baseline management.
Synthetic transaction monitoring — checking that a complete purchase or form submission works end-to-end is valuable for high-stakes client sites but is expensive to maintain correctly. Start with this only when SSL, DNS, and uptime basics are covered.
Alert Routing Is Where Most Monitoring Setups Break Down
The most common failure mode in agency monitoring: all alerts go to one email address or Slack channel, and everyone develops alert fatigue.
Effective alert routing for agencies:
Route by client, not by severity alone. The account manager for a client is the right first responder for that client's alerts — they have the client relationship, they know the context, and they can decide whether to escalate.
Route by severity within clients. SSL expiry at 60 days goes to the account manager for scheduling. SSL expiry at 14 days goes to the account manager and the technical lead simultaneously. SSL expired (zero days) goes to whoever is on call, immediately.
Suppress planned-change noise. When you make a planned DNS change, suppress the monitoring alert for that record for the next 30 minutes. Alerts during planned maintenance windows are not useful.
Create escalation paths. If an alert is not acknowledged within 30 minutes, who gets notified next? If the account manager is not available, who is the backup? Document this, even if it is simple.
The Audit Trail Requirement
Increasingly, client contracts include SLA provisions about monitoring and uptime. Clients ask "what was the SSL status of my site on this date?" as part of renewal discussions or incident post-mortems.
Without monitoring, the answer is "we don't know." With basic uptime monitoring, the answer is "it was up or down at these times." With asset monitoring, the answer is "here is the exact certificate state, DNS record state, and vendor dependency status for any point in time you specify."
The audit trail has direct commercial value. It closes disputes, demonstrates professionalism, and justifies the monitoring cost in concrete terms.
Building Monitoring Into Client Onboarding
The time to set up monitoring is not after the first incident. It is at the start of every client engagement, as part of onboarding.
A monitoring-first onboarding checklist:
- Identify all domains and subdomains in scope for the engagement
- Record current SSL certificate state — expiry date, issuer, SAN list
- Record current DNS record state — A, CNAME, MX, TXT, NS, CAA
- Identify upstream dependencies — which third-party platforms does the site use?
- Configure alert recipients — which account manager, which technical contact?
- Document renewal responsibilities — who renews the SSL certificate? Who has DNS access?
- Set calendar reminders for manual reviews — quarterly is a reasonable cadence for non-critical sites
With this done at onboarding, monitoring runs automatically. Problems surface before they reach the client. The audit trail starts from day one.
Merlonix handles the technical side of this checklist — SSL monitoring, DNS drift detection, and vendor status aggregation — across your full client portfolio. See how it works →
→ Complete guide: Agency Monitoring: The Complete Guide to Monitoring Client Websites at Scale → See also: Monitoring for WordPress Agencies → See also: Monitoring for Shopify Agencies