How to Monitor Client Websites: A Monitoring Playbook for Agencies

If your agency looks after twenty, fifty or a hundred projects, you often find out about outages the worst possible way: a phone call from the client. The missing piece is rarely a tool. It's structure. To monitor client websites properly, adding every homepage to a monitoring service isn't enough. You need clear answers to three questions: what gets checked for each project, who responds to which alert, and how all of it fits into your maintenance agreements.

In this article we walk through how we would set up monitoring for an agency, from taking inventory and choosing checks per site to alert routing and offboarding when a project ends.

Why monitoring client websites is its own discipline

Monitoring a single company website is manageable. Agencies deal with a few extra complications:

• Many environments, little consistency. One project runs on managed WordPress hosting, the next on a dedicated server with Laravel, the third on a hosted shop platform. Each one fails in its own way.
• Shared responsibility. The client often controls the domain, hosting or DNS, while the agency is held responsible for the website. When something breaks, the question still ends up with you.
• Changing people. Projects get handed over, freelancers come and go, and responsibilities shift. Monitoring that only one person understands rarely survives that.
• Contractual commitments. Many agencies sell maintenance or support retainers. Once you do, you should be able to show when a site was up and when it wasn't.

That's why good monitoring for agencies is mostly an organizational job, supported by a technical tool.

Step 1: Take inventory of every client project

Before you create the first monitor, get an overview. A simple spreadsheet is fine as long as it's complete. For each project, note:

1. Every domain, including redirect, campaign and typo domains.
2. Key pages and endpoints, such as the homepage, contact form, checkout, login, API or webhook receivers.
3. Recurring jobs: backups, imports, newsletter sends, feed exports, cache warmers.
4. Who manages what: registrar, hosting, DNS, SSL certificate. The agency or the client?
5. What the contract says: Is there a maintenance agreement, a response time, a contact person on the client side?

The inventory has a side effect that's often worth more than the monitoring itself. You'll find projects nobody owns anymore and domains registered on personal accounts of people who left years ago.

Step 2: What to check on each client website

Not every project needs the same checks. Here is a sensible baseline for a typical client site.

Availability of the pages that matter

The classic check is an HTTP request to the homepage. It tells you whether the server responds and which status code it returns. For shops and web apps that's not enough: the homepage may be served from a cache while checkout fails with a 500. Add monitors for the pages your client actually makes money or gets leads from.

Pay attention to the status code you expect. A page that returns 200 but shows a CMS error message is just as broken for visitors as a 503. A keyword check helps here: the monitor alerts you when a specific piece of text is missing from the page, such as the label on the add-to-cart button. Our guide to HTTP status codes explains what each code means for monitoring.

SSL certificates and domains

Expired certificates and missed domain renewals are among the most frustrating outages because they're entirely predictable. When the client holds the domain or hosting, you otherwise only see the problem once it's too late. We cover both in detail in SSL certificate monitoring and domain expiration monitoring.

Cron jobs and background tasks

Many failures are invisible from the outside. If the nightly backup stopped running three weeks ago, the website still returns 200. You monitor jobs like these with heartbeats: the job calls a ping URL after a successful run, and if the ping doesn't arrive, you get an alert.

WordPress deserves a special mention because agencies run so much of it. WP-Cron isn't a real cron; it's triggered by page views. On low-traffic sites, scheduled tasks run unreliably, and behind a full-page cache they may barely run at all. A more robust pattern is to disable WP-Cron in wp-config.php:

define( 'DISABLE_WP_CRON', true );

and run due events from a system cron job with WP-CLI instead, backed by a heartbeat:

*/5 * * * * cd /var/www/client-a && wp cron event run --due-now > /dev/null && curl -fsS -m 10 --retry 3 https://kaspar.app/p/YOUR_TOKEN > /dev/null

The same applies to Laravel projects: monitor whether schedule:run is being called at all, and protect important tasks with pingOnSuccess(). Ping URLs, grace periods and exit codes are covered in our guide on how to monitor cron jobs with heartbeats.

Broken links

A relaunch, a permalink change or a content cleanup quickly leaves broken links behind. They don't take a site down, but they hurt user experience and SEO, which many agencies are responsible for too. A regular crawl of the whole site surfaces new errors before the client spots them in Search Console. Our article on how to find broken links and protect your SEO shows how to approach it.

Step 3: Keep your monitoring organized

With a handful of monitors, organization doesn't matter. With several hundred, it decides how quickly you respond when something breaks.

Keep clients separate. Each client should get its own space where their monitors, alert channels and contacts live together. You see at a glance which client is affected, and you can invite project members without giving them access to every other project.

Use consistent names. A pattern like Client – Project – Check (for example "Miller Inc. – Shop – Checkout") makes an alert understandable without any extra context. Whoever gets paged at night shouldn't have to work out what "Monitor 47" is.

Group across clients as well. Besides the client, attributes like environment (production, staging), hosting provider or maintenance plan are useful. When a host has an outage, you can filter all affected projects in seconds.

Keep the list current. Monitors for sites that were shut down long ago produce false alarms and dilute attention. Make updating monitoring part of every project handover and every cancellation.

Step 4: Route alerts to the right people

The most common weakness in agency setups isn't a missing check but the wrong recipient. An alert that lands in a shared inbox nobody reads is barely better than no alert.

• Send every alert to a channel someone actually reads. For most agencies that means Slack or Telegram for active outages, and email for advance notices like expiring certificates.
• Don't route alerts through the infrastructure you're monitoring. If the client's email runs on the same domain as the website, an outage email may not reach them exactly when it matters.
• Decide whether the client gets alerted too. Some clients want to know immediately, others only when an outage lasts longer. Write it down in the contract or project documentation.
• Connect your own systems with webhooks. If your agency uses a ticketing system or its own on-call tooling, a webhook is the cleanest way to feed alerts into it automatically.
• Avoid alert floods. When a server hosting twenty client sites goes down, twenty separate messages help no one. A single summary is far more useful.

You also need a clear rule for who responds. Who is on call this week, who covers evenings and weekends, and when does the client get informed? Without that agreement, everyone sees the alert and everyone assumes someone else is on it.

Step 5: Build monitoring into maintenance contracts

For agencies, monitoring isn't just insurance. It's also a visible part of the service you sell. For that to work, the contract and the technical setup need to match.

Spell out what's monitored. Instead of "we monitor your website", be specific: availability of the homepage and shop, SSL certificate, domain, nightly backup, regular broken-link scans.

Separate detection from response. A monitoring service detects an outage within minutes. How quickly you respond is a different promise that depends on office hours and on-call coverage. Don't merge the two into a single number.

Be careful with uptime guarantees. If hosting, DNS or the domain sit with the client or a third party, you can't guarantee their availability. An honest phrasing is: we detect outages and act on them within the agreed scope.

Use the history. Downtime and response times over recent weeks are a solid basis for conversations with the client, for instance when a hosting move is on the table or performance problems come up.

Step 6: Make onboarding and offboarding routine

Monitoring only stays accurate when it's built into your project workflow.

When onboarding a new project, monitors belong on the same checklist as backups and credentials: create the monitors, assign alert channels, add heartbeats to cron jobs, send a test notification. Only then is the project officially taken over.

At go-live after a relaunch, take a focused look: are the monitored URLs still correct, do old addresses redirect instead of returning 404, and has the text your keyword check looks for changed?

When offboarding, pause or delete the monitors, remove the client from your alert channels and document who is responsible from now on. That way you don't get alerts for sites you no longer look after, and clients stop receiving messages from an agency they no longer work with.

Common mistakes when monitoring client websites

To wrap up, here are the patterns we run into most often:

• Only the homepage is checked, even though the shop or the contact form is what really matters.
• Cron jobs aren't monitored at all because everything looks fine from the outside.
• All alerts go to one person who happens to be on vacation.
• Monitors for retired projects keep running and create noise.
• The client holds the domain and certificate, and nobody tracks the deadlines.

Each of these is easy to fix once it's visible.

How Kaspar helps agencies monitor client websites

We built Kaspar so this whole workflow comes together in one tool. You keep each client in its own workspace and invite colleagues, and one plan per account covers all your workspaces. Tags let you group monitors further, for example by environment or hosting provider, and filter the monitor list by tag.

In each workspace, Kaspar checks your sites' availability with status code and keyword checks, warns you 30, 14, 7 and 1 day before an SSL certificate expires, keeps an eye on domain expiration dates, and monitors cron jobs with heartbeats. On the Pro plan, link monitoring scans entire websites for broken links on a schedule. We send alerts by email, Slack, Telegram or webhook, with reminders while an outage lasts and a single digest when several monitors fail at once. You can find an overview of all features and our pricing on our website.