Monitoring 1 site or 100: what really changes

The tool barely changes between one site and a hundred. What changes is everything around it: how things are named, who hears about a problem, and what you do on the morning twelve sites go down together.

If you look after fewer than about five sites, none of what follows applies. A list and your memory are a perfectly good system, and building process around five sites is how people avoid doing the work.

What breaks first: naming

At five sites you know which is which. At forty you get an alert saying prod-2 is down and you spend four minutes finding out whose it is. Those four minutes come back on every alert, every report and every search.

Decide a convention before you need one, and make the client the first thing you read:

client (site) role
dupont-joinery (brochure) prod
dupont-joinery (shop) prod
saint-clair-council (portal) prod
saint-clair-council (portal) staging

Three rules make it last ten years. Client first, because that is the first question you ask in front of an alert. No private abbreviations: scc-portal-p2 was obvious the day you wrote it and is obvious to nobody now. Role at the end, so staging and production are distinguishable without opening the record.

It is unglamorous, and it is the single change that saves the most time.

Group by criticality, not by client

The second instinct is to file sites by client. That is convenient for invoicing and useless during an incident: what decides your reaction is not who owns the site, it is what it costs when it falls over.

Three or four groups are enough, and most of the estate lands in the last two. That is normal, and it is the point: an estate where everything is critical is an estate where nothing is. The grouping is also what makes the estate transferable: a colleague picking it up needs to know which four sites matter before knowing anything at all about the other thirty-six. The interval per group is chosen from cost, exactly as it is for a single site.

Who hears about it

The instinct is to send everything to everyone. It produces a group of people who all assume someone else is handling it.

Decide per site: one person responsible, and for the client, only what they can act on. A client who receives a 3 a.m. alert and phones you at 9 to ask about it has cost you two interruptions instead of one.

The related question, what actually deserves to become a notification, has its own answer, and it matters more than the interval as soon as the number of sites grows: twelve sites checked every five minutes with no confirmation rule produce a volume of noise that kills the monitoring within a month.

The morning twelve sites fail at once

This is the moment that separates a list from a system. Twelve alerts arrive. They are almost certainly one cause: a shared host, a DNS provider, an expired certificate on a wildcard domain.

What you need in that moment is not twelve notifications. It is the ability to see, in one place, what the failing sites have in common: same server, same provider, same technology, same registrar. If your organisation cannot answer that, you will debug the same incident twelve times.

Concretely that means one thing: every site must carry, somewhere, who hosts it and where its DNS points. A column in a spreadsheet is enough. It earns its keep twice a year, and on those two occasions it turns a morning into ten minutes.

What follows matters just as much: the first fifteen minutes do not change because there are twelve sites rather than one. You confirm from outside, locate the layer at fault, and look for what changed, except that you do it once rather than twelve times.

Going from five to forty, in practice

The tipping point does not happen at a precise number. It happens at three signs, and they almost always arrive in this order.

You open an alert and you do not know which site it is. That is the naming signal, and it is the first job.

You can no longer say which ones are being watched. A site added eight months ago was never registered, and nobody will notice until it falls over. That is the inventory signal: the list of sites you manage and the list of sites you monitor have to be the same list, compared once a quarter.

You have stopped reading the notifications. That is the most serious signal, because it is silent. At that stage, adding sites adds nothing at all.

The work is always the same, in the same order: name, group, decide who receives what. No tool does those three things for you, which is also why changing tools almost never solves the problem.

What you should be able to answer in thirty seconds

A well-run estate is recognised by five questions, not by its dashboard.

• How many sites do you manage, and how many are monitored?
• Which one would cost the most if it fell over?
• Who hosts each of them, and where does its DNS point?
• Which certificate expires first, and in how many days?
• Which site has had the most incidents over the last three months?

If all five answers require a search, the problem is not the monitoring, it is the inventory. And the fifth question is the one that on its own justifies keeping a history: it is also what fills a client report.

Inherited sites, the ones nobody looks at

Every estate has some. A site taken over from a previous supplier, an event page from 2021 still online, an old domain that redirects.

Watch them anyway, with the loosest settings you have. An inherited site failing is exactly the one nobody notices, and the one you will be blamed for, because it carries your name on the invoice. A daily check costs almost nothing and avoids the most unpleasant conversation in this trade: "how long has it been like that?", followed by "I don't know".

It is also in this category that certificates expire silently, since nobody ever opens those pages.

What organisation does not replace

It does not replace knowing what each site does. A dashboard showing green across forty sites does not say the forty are working: it says forty homepages answer. A client's checkout can have been dead for three days without a single row changing colour.

Nor does it replace server-side monitoring, which sees what an outsider cannot, or the reverse: your host will warn you about nothing, however many sites you place with them.

The rhythm, not the tool

Past a certain number of sites, monitoring stops being an event and becomes a routine: a weekly glance at what changed, a monthly pass that turns into something you send the client, and a rule about what you do with the sites that have been quietly failing for three weeks.

The tool tells you what is broken. The routine is what makes anything get fixed.