The worst way to learn your website is down is a customer telephoning to tell you. The second worst is an alert that arrived four hours ago in a folder nobody opens.

Effective monitoring is less about tooling than about deciding what matters and who is told.

What a small business should monitor

The website, from outside

An external check every few minutes, from a service unconnected to your infrastructure. This matters: a check running on your own network reports success when your internet connection fails.

Monitor more than the homepage. Check a page that requires the database, and if you sell online, check that the basket and checkout respond. A homepage served from cache can be fine while the shop is broken.

Email flow

Both directions. Businesses discover inbound mail has been failing when a customer asks why nobody replied to their order three days ago.

Also monitor whether your mail is being delivered rather than filtered, which is a function of your authentication records — see SPF, DKIM and DMARC explained.

Backups

That they ran, and that the result is plausible. A backup job reporting success while producing a file a fraction of its usual size has failed in the way that matters.

Disk space

With a trend rather than only a threshold. A server that has been at eighty per cent for two years is stable; one that reached eighty per cent last Tuesday is a problem arriving.

Certificate and domain expiry

Sixty days' notice. Both cause complete outages, both are entirely predictable, and both still catch businesses out annually.

Unusual authentication

Sign-ins from unexpected locations, bursts of failures against one account, or authentication from two places too far apart to be the same person. These are the earliest indications of a compromise.

Setting thresholds that work

This is where monitoring succeeds or fails.

Alert on the symptom customers feel, not on every metric. Processor usage at ninety per cent is interesting. The website taking eight seconds to respond is actionable.

Require duration. A single failed check may be a network blip. Three consecutive failures is an outage. This one change removes most false alarms.

Set thresholds where action is still possible. Alerting at ninety-five per cent disk usage leaves no time. Alerting at eighty per cent, with the trend, allows a planned response.

Distinguish urgency. Two categories are enough for most businesses: wake somebody up, and look at it tomorrow. Everything that is not the first should be the second.

An alert that does not require an action should not be an alert. It should be a line in a weekly summary.

Avoiding alert fatigue

Monitoring set up without discipline produces dozens of daily messages, most of which mean nothing. Within a month people filter them, and the real one is missed.

Guard against it:

  • Every alert has an action. If nobody knows what to do when it arrives, it should not exist.
  • Review what fired monthly. Anything that fired repeatedly without requiring action gets its threshold adjusted or gets deleted.
  • Group related alerts. One server failing should produce one notification, not fourteen.
  • Suppress during planned work. A maintenance window that generates alerts teaches people to ignore them.

Who gets told

The most common failure is technically perfect monitoring sending alerts to a mailbox nobody watches.

Decide, per alert: who receives it, by what route, and what is expected of them.

For anything critical out of hours, that means a route that will actually reach somebody — a phone, not an email — and a named person or a support provider with a contractual duty to respond.

Have a fallback. If the first person does not acknowledge within a set time, it escalates. Without this, an alert at 11pm to somebody who is asleep is the same as no alert.

Watch the watcher

Monitoring that stops running produces silence, and silence looks identical to everything being fine.

Use an external service where possible, so it does not share fate with what it monitors. And have anything critical send a periodic confirmation that it is alive, so the absence of a message is itself detectable.

What to do after an alert

The value of monitoring is realised in the response, not the notification.

Keep a short record of each incident: what alerted, what the cause was, what was done, and what would prevent it recurring. Over a year this tells you where the real weaknesses are, and it is what turns repeated firefighting into fewer fires.

It also feeds directly into an incident response plan — see a small business incident response plan.

Where to start

External website checking, backup verification and certificate expiry. Three checks, all cheap, covering the outages that most commonly reach customers.

Our maintenance team monitors systems for UK businesses with alerts routed to people rather than to mailboxes. Start a conversation.