How to monitor client websites as an agency
Keep every client's sites, certificates and DNS checks in one list, grouped by client, and send each client's alerts where they belong.
Keep customers informed · 4 min read · Updated Oct 12, 2026
When a client's site goes down, the worst way to find out is from the client. The second worst is an alert that says "example-prod-2 is down" at 2 a.m. and leaves you working out whose site that is.
Agencies end up with dozens of small sites, each with its own host, certificate, DNS and renewal dates, and nobody watching any single one closely. This guide sets up monitoring so that each client is covered the same way and an alert tells you whose site it is about.
How it works
Three things keep monitoring manageable across many clients.
- One name per client, used everywhere. In the name of every check and in a label on it, so lists and alerts can be read per client.
- The same set of checks for each client. A short standard list, applied to everyone, beats a careful setup for the three biggest clients and nothing for the rest.
- A clear rule for who is told. Decide per client whether an alert goes to you, to the client, or to both.
Step 1: Name things by client
Pick one short name per client and use it without variation. "acme" and "Acme-Ltd" are two clients as far as any tool can tell.
Put that name at the start of every check's name: "Acme shop", "Acme certificate". The check's name is what an alert shows, and at 2 a.m. it is all you will read.
Step 2: Cover the same things for every client
A sensible standard set:
| What | Why |
|---|---|
| The home page | The check that tells you the site is down. |
| The page that earns money | A contact form, a booking page or a shop can break while the home page is fine. |
| The certificate for each host | See how to get alerted before an SSL certificate expires. |
| The domain's DNS | See how to monitor DNS records. |
| Backups and other scheduled jobs | See how to monitor a cron job. |
Many client sites are cached at the edge, so the home page stays up while the form behind it fails. That is why the second row matters most.
Write the list down once and use it for every new client. Onboarding a client then includes "set up the standard checks", like setting up their hosting does.
Step 3: Decide who hears about each client
Two rules cover almost every agency:
- One rule for everything, sending every alert to your own team's channel.
- A second rule per client who wants it, sending that client's alerts where they ask: their own email address, or their chat.
A check that no rule covers tells nobody. The one rule for everything is what prevents that.
Decide it with the client. Some want to hear at once. Most want to hear from you, with an explanation.
Step 4: Give the client somewhere to look
A status page turns "is it down?" emails into a link. Give each client who asks often their own page, showing their site's checks, on their own address if you can: see how to set up a status page on your own domain.
Step 5: Know when a client needs their own account
Labels are enough while your team does the watching. A client who wants their own sign-ins, their own members and their own invoice needs real separation. Decide that per client, not as a default: separation costs upkeep, and often money.
Test it
- Pick one client and list their checks. Everything on the standard list is there.
- Add a temporary check, named and labelled for that client, that cannot pass, such as one expecting text that is not on their home page. It fails, and the alert that arrives names the client and goes where that client's alerts should.
- Remove it.
Common mistakes
- Naming by hand, inconsistently. Pick the short name once.
- Monitoring only the home page.
- Alerts that go to one person. Use a shared channel, and an on-call rotation once there is more than one of you.
- Forgetting the things that expire. Certificates and domains lapse on a date, not after a deploy.
- Setting up the big clients carefully and the small ones not at all. The standard set is the point.
Doing this in saysOK
The label is a tag in the form project:acme. Add from a domain looks at a client's domain from outside, proposes the checks for it, and tags the monitors it creates that way. On the monitor list, Group by then shows one section per client.
Alert rules apply to All monitors or By tag, which gives you the two rules from step 3.
Those rules cover monitors. A heartbeat is listed on its own page, is not grouped by tag, and tells the channels chosen on it, so give each one the client's name and choose its channels when you create it. A client who needs separation gets a workspace of their own, created from the workspace switcher; each workspace is on its own plan.
For what saysOK offers agencies and how the plans are priced, see saysOK for agencies and pricing.
Next
When you look after more sites than people, who gets woken matters: see how to set up an on-call rotation for a small team.
Set this up in saysOK
Start on the free plan. The guide says where a step needs a paid one.