Imagine a dental clinic whose new patients mostly arrive through an appointment form on its website. On Friday evening the hosting company renews its servers, and the form starts returning an error. The home page still loads, so nobody at the clinic notices. On Monday morning a patient calls to ask why nobody answered her request. By then the form has been failing for almost three days, and nobody knows how many people gave up and booked somewhere else.
Nothing dramatic happened here. No attack, no lost data, no expensive system. A small part of a small site stopped working, and the only alarm the business had was a customer who cared enough to call.
Monitoring is often treated as something for large platforms with operations teams. In practice it matters most for small businesses, because they have no one watching the site and every lost enquiry is noticeable. The good news is that the basics are cheap and take an afternoon to set up.
1. Check from outside, not from the server
A server can report that it is healthy while visitors cannot reach it: the domain may point to the wrong address, a firewall rule may block traffic from certain countries, a certificate may have expired. The only check that reflects what a visitor sees is one made from outside, over the public internet, the way a browser would.
Use an external monitoring service that requests your site every few minutes from more than one location. Most of them have a free or very cheap tier that is enough for a small business. If one location fails and the others succeed, you learn that too, which helps when the problem is regional.
2. Check the page that earns money, not just the home page
In the clinic example the home page never went down. The form did. A monitor that only asks "does the home page respond?" would have stayed green all weekend.
List the two or three pages or actions that bring in business: the contact or booking form, the product page and checkout, the login page for customers. Monitor each of them directly. For forms, a monitor can look for a specific word on the confirmation page, or the developer can add a small health endpoint that confirms the form's email or database connection still works. A check that looks for a word on the page is stronger than one that only accepts any response, because error pages also respond.
3. Send the alert to someone who can act, and to a second person
An alert that goes to an inbox nobody reads at the weekend is a log entry, not an alert. Decide who receives it, through which channel, and what they are expected to do. For a small business that might be the owner by text message and the developer or agency by email.
Always add a second person. People travel, turn their phones off and change jobs. Also decide how long a failure must last before anyone is woken up; a single failed request is often a brief network hiccup, while several minutes of failure is worth a message.
4. Watch the things that expire
A surprising share of small-business outages are not technical failures at all. The domain was not renewed because the card on file had expired. The security certificate was not renewed, and browsers now show a full-page warning. The hosting account was suspended over an unpaid invoice sent to a former employee's address.
Monitoring services can warn you weeks before a certificate or a domain expires. Turn those warnings on. Then check whose name and email address are on the domain, hosting and certificate accounts, and make sure they belong to the business, not to a person who might leave.
5. Write a one-page note on where to look first
When an alert arrives, the person receiving it should not have to work out from scratch where the site is hosted and who to call. One page is enough: where the domain is registered, where the site and its database are hosted, who has access, who the developer is and how to reach them, and how to put up a simple "we'll be back shortly" page with a phone number.
Keep this page somewhere you can reach even when your own systems are down, not only on the server that just failed.
6. Record what happened, briefly
After each outage, write three or four lines: when it started, when it was noticed, what caused it, what was changed so it does not happen again. Over a year these notes show patterns that are invisible one incident at a time, such as every outage following a hosting update, or always starting with an expired payment.
The gap between "when it started" and "when it was noticed" is the number to watch. If monitoring is working, it should shrink to minutes.
7. Check again after every change
Many outages begin with a release, a plugin update or a hosting change. After every change, someone should open the pages from step 2 and use them as a visitor would: send the form, add a product to the cart, sign in. A monitor will catch what breaks hours later, but a two-minute manual check catches what breaks immediately.
In short
- Monitor the site from outside, from more than one location.
- Monitor the pages and forms that bring in business, and look for a specific word, not just any response.
- Send alerts to someone who can act, and always to a second person.
- Turn on warnings for domain and certificate expiry, and keep the accounts in the business's name.
- Keep a one-page note on where to look first, somewhere outside your own systems.
- Write three or four lines after each outage.
- Test the important pages by hand after every change.
In our cloud and DevOps work, monitoring and alerts are part of the setup rather than an extra, so the client usually hears about a problem before their customers do.
Planning a project like this?
Plan it in 10 steps