Spreadsheets, Reminders and Manual Checks: Why Manual Monitoring Fails Sooner or Later
Few web agencies reach a proper monitoring tool as their first choice. Almost all get there after trying, and watching fail, one of these three systems, often in sequence.
The three ways client sites get checked before a real tool
Eyeballing. No system: someone at the agency opens the clients' sites "when they think of it", maybe on Monday morning, maybe only when a client comes up on a call. It works as long as the number of sites is low and the memory of whoever does the checking is good.
The spreadsheet. A step more structured: one row per client, one column for the domain expiry, one for the SSL certificate, maybe a note saying "checked on [date]". It's already better than nothing, but it has the same limit as eyeballing: someone has to open it, update it, and above all remember to do so. The spreadsheet remembers nothing on its own; it only flags what someone has written into it.
Uptime Kuma installed and then forgotten. The most mature step: a real monitoring tool, free and open source, installed on one of the agency's servers. It works better than the first two, since it really does check, automatically, but it introduces a new problem: now there's another server to maintain, update and, above all, watch. (What it does well and what it doesn't is covered in the dedicated review; the head-to-head numbers are in the Statuo vs Uptime Kuma comparison.)
Why they all fail the same way
Eyeballing, the spreadsheet and even unmanaged Uptime Kuma share the same weak point: they work as long as someone remembers. And sooner or later, in every agency, there comes a time when nobody remembers anymore. Not out of negligence, but for the most mundane reasons: the person who checked the spreadsheet went on vacation, the manager changed and nobody passed the habit on, or the clients simply became too many to keep in your head one by one.
It isn't an individual failing. It's a structural limit of any system that needs a recurring human action to work: sooner or later, that action gets skipped.
The moment it breaks
Almost never is the breakage found by an internal check, such as an owner rereading the spreadsheet and noticing a box that's been empty for three months. Almost always it's found because a client calls, angry: the site has been down for hours, or the SSL certificate has expired and visitors see a security warning, and the agency's first news of it is that phone call.
It's the worst possible moment to find out: the client has already lost trust before you've even started fixing it, because the implicit question in that call isn't "can you fix it?", it's "how long have you known?".
Checking versus alerting: the difference that matters
The real step up isn't going from "nothing" to "a tool". It's going from a tool you have to consult to one that alerts you on its own. A spreadsheet, however well kept, always requires someone to open it. A real monitoring tool reverses the direction: you're not the one checking whether the site is up, the tool writes to you when it isn't.
It's a small difference to describe and an enormous one to live with: in the first case the time between the outage and discovering it depends on how often someone looks; in the second it depends only on how quickly the tool confirms the problem, usually minutes, not days.
If you already have Uptime Kuma: the risk you can't see until it happens
Anyone who has reached the third stage, a working Uptime Kuma instance, has already solved the "nobody remembers" problem. But one specific risk remains, silent until it shows itself: if the server hosting Kuma goes down, you don't just lose monitoring, you don't know it, because the system that should alert you is the very one that went down. Who monitors the monitor? The project itself acknowledges this, to the point that its documentation devotes an entry to "downs that aren't downs", the typical symptom of an instance observing from a single point on the network. It's not a flaw in Kuma: it's the limit of any single-instance self-hosted system. The full discussion, with the numbers on the real cost of self-hosting, is in the Statuo vs Uptime Kuma comparison.
How to move to a managed service without switching off cold
The most common fear, "what if I miss an important alert during the switch?", is solved with a parallel transition, not a hard cutover:
- Add the sites to the new tool (name and URL, nothing to install) while keeping whatever system you're already using running in parallel: spreadsheet, eyeballing or Kuma.
- Let the two systems coexist for a few days. This is to check that the new tool really sees everything the old one saw, before you trust it fully.
- Switch off the old system only once you've seen the new one work on a real case, even just an SSL alert or a small confirmed slowdown.
There's no day on which you "stop" being protected: there's a week in which you're protected by two systems instead of one.
Free trial, no credit card
Statuo is built precisely for this move: you add your clients' sites in a few minutes, there's no server to install or maintain, confirmation from multiple locations before every alert, and a status page under the agency's brand ready to show. The trial lasts 14 days, with no credit card: enough time to run it alongside the system you use today and see whether the first alert comes from the tool rather than from a client.