Website monitoring: who notices when your site breaks? A small-business guide (2026)

What breaks quietly

When people think of a broken website they think of a hacked WordPress install with casino links in the footer. That happens, but it is rarely what costs. What costs are the faults nobody sees, in the order I run into them:

• The form that stopped sending. The email key was rotated, the quota is used up or the domain lost its verification. The page says "thanks for your message" and nobody receives it. That can go on for weeks.
• Scheduled jobs that die. Reminders, purging of personal data, nightly refreshes. They are not visible in the browser and therefore not in any check that only looks at the homepage.
• The certificate. Most providers renew it automatically these days, but a domain move can trip it. I have watched a certificate flicker between valid and invalid for hours because old DNS records were left under the address. The visitor sees a red warning and leaves.
• Dead links. Pages removed while other pages still point at them. On my own site a button to a deleted page sat there for months until I had a script crawl all 154 pages. Google had found it long before I did.
• Components with known vulnerabilities. A modern site is made of hundreds of packages by other developers. When one of them gets a known security hole it is in a public database the same day. The question is whether anyone checks your site against it.
• The site that got slow. One new image in the wrong size, one more plugin, and the homepage takes three seconds on mobile. Nobody complains, they just leave.

Four checks every night

The watchdog I run for my clients goes through one site at a time, every night, and does four things. None of them requires anyone to be awake.

1. Does the site respond? One request to the domain. A server error counts as critical and goes to the top.
2. Is the certificate valid? The expiry date is read. Fewer than seven days left is critical, regardless of whether the provider "usually" renews it.
3. Does any component have a known vulnerability? The site’s exact package list is looked up against the open OSV vulnerability database. Only what the database actually returns is reported. The agent may not claim a hole from memory, because a warning that is wrong costs more than no warning.
4. Is it still fast and readable? A Lighthouse run on mobile. Below 70 in performance or below 80 in accessibility becomes a warning, not an alarm.

The findings land with me, not with the client, sorted by severity and by how urgent they are: today, this week or later. I read, fix, and tell the client when it is done. The same finding is not reported over and over unless it has got worse. It is the same principle as in the weekly report: the agent reads and flags, a human decides.

What no status check sees: the site that works, but wrongly

The most important thing I learned about monitoring I learned on 14 September this year. Three of my client sites had green builds, answered every request and looked perfect. Yet their scheduled jobs had been dead for weeks: reminders to customers, purging of personal data, nightly refreshes. The cause was one line in a configuration file. The environment variables were set at the provider but not declared in the build, so the code that was supposed to run the jobs never saw them. The provider had written it in the build log, as a warning, next to a green tick. Nobody reads warnings next to green ticks.

The conclusion is simple and uncomfortable: a status check only answers the question "is the site up?". It does not answer "did the reminder go out yesterday?". So I now monitor outcomes, not just status. Did the week’s mailing go? Did the test booking arrive? Did the purge run last night? It is also why the weekly report refuses to send itself when a week looks empty: a site that normally has activity and suddenly has zero has probably not gone quiet, it has stopped measuring.

The free route: five things you set up tonight

1. A free uptime check. Services like UptimeRobot request your site every five minutes and email you when it does not respond. It takes five minutes to set up and catches the most embarrassing fault: the site being down all weekend without you knowing.
2. Search Console’s own emails. Google emails you for free about indexing errors, security issues and manual actions, if you are a verified owner and have the emails switched on. It is the only check that sees the site the way Google does.
3. A date for the domain. The domain renews once a year and the card that pays for it changes more often than that. Put the expiry date in the calendar a month ahead. An expired domain is the only fault here that cannot be fixed in a quarter of an hour.
4. One test form a month. Send yourself an enquiry or a booking from the site, from your phone, on the first of every month. If it does not arrive you know now and not in eight weeks.
5. Read the warnings. At every update of the site: open the build log and read what is in yellow, not just the tick. It is free, and it would have saved me three weeks of dead jobs.

When it is worth letting an agent do it

If you have an information site with a contact form, the free route above is enough, and I would rather say so than sell you something. The watchdog is for sites that do things: take bookings or orders, send reminders, run jobs at night. There the value is not the site’s status but that someone looks the components up against the vulnerability database every night, reads the certificate and notices when speed drops, without you having to remember it. With me it is included from the Pro tier, and what each tier contains is listed openly under services. How such an agent should be built so it never does harm when it is wrong is in the guide on AI agents, and you can read who is behind it under about me.