Guides

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:

WhatWhy
The home pageThe check that tells you the site is down.
The page that earns moneyA contact form, a booking page or a shop can break while the home page is fine.
The certificate for each hostSee how to get alerted before an SSL certificate expires.
The domain's DNSSee how to monitor DNS records.
Backups and other scheduled jobsSee 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

  1. Pick one client and list their checks. Everything on the standard list is there.
  2. 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.
  3. 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.

Monitors
acme1 down · 2 up
Acme shopshop.acme.example
Down
Acme websiteacme.example
Up
Acme certificateacme.example:443
Up
nordlicht2 up
Nordlicht websitenordlicht.example
Up
Nordlicht bookingbooking.nordlicht.example
Up
The monitor list grouped by the project tag: one section per client.

Alert rules apply to All monitors or By tag, which gives you the two rules from step 3.

Alert rules
Anything goes downApply to: All monitorsTells your team's chat
Acme outagesApply to: By tag · project:acmeTells Acme's own email address
One rule for everything, and a second for a client who wants their own alerts.

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.