Monitoring for Small Systems: Enough Signal Without an Enterprise Budget

Monitoring for Small Systems: Enough Signal Without an Enterprise Budget

Three checks cover most of it, and they're free or cheap: external uptime, cron heartbeats, and disk-plus-certificate alarms. Together they catch nearly every failure that takes down a small system. Add one alert channel people actually read, and the whole setup is done in a day. No enterprise dashboard needed.

Nearly every small business I work with eventually gets a sales call from Datadog or New Relic: full-stack dashboards, distributed tracing, anomaly detection across every host. None of it earns its cost for a company running three to eight servers — the bill scales with hosts and data volume, and someone still has to build the dashboards and staff the on-call.

Datadog and New Relic exist to answer "which of our 400 microservices is causing the P99 latency spike in checkout." A shop running an ERP, a website, and a couple of cron jobs on four servers has a smaller, more boring problem: is the server up, did the backup run, is the disk full, is the certificate about to expire.

Buying a platform built for hundred-node fleets to answer four yes/no questions is like renting a shipping container to move one suitcase.

The minimum viable signal set

Three checks catch nearly everything that goes wrong at this scale. External uptime checks confirm the site is reachable from outside your network. Application and cron heartbeats confirm the scheduled jobs actually ran. Disk space and certificate expiry alarms catch the two silent killers.

Get these three right, add one alert channel someone actually reads, and you've covered the failures that actually take down small systems.

External uptime checks, done cheap

The cheapest and most reliable signal is also the most basic: a ping from outside your own network that tells you the site is down before a customer calls to tell you.

UptimeRobot's free plan covers 50 monitors at five-minute intervals, with HTTP, port, keyword, DNS, and SSL/domain expiration monitoring built in, no credit card required — more than most SME setups will ever need.

If you'd rather not depend on a third party, or you're already paying for a small VPS, Uptime Kuma is a self-hosted, open-source alternative under the MIT license. It watches HTTP(S), TCP, keyword, ping, and DNS targets, includes a dedicated SSL/TLS certificate expiry monitor, and ships notification integrations for Telegram, Discord, Slack, email, and more than ninety other services.

Either option answers the same question a customer complaint would otherwise answer for you: is the front door open.

Heartbeats: catching the job that quietly stopped running

The failure external uptime checks miss is the cron job that stops firing. The web server keeps answering 200 OK. The invoice-generation script silently stops running, and nobody notices until someone asks where last week's numbers went.

The fix is a dead man's switch. Healthchecks.io documents the pattern well: the job pings a URL when it finishes, using curl or wget already installed on the server. If the ping doesn't arrive on schedule, the service alerts you.

It catches what an uptime check can't: the machine going down, the cron daemon not running, the job exiting non-zero, or a job still running long past when it should have finished. I use the same pattern for scheduled polling jobs in IoT backends — see the guide to IoT backend architecture.

Disk and certificate expiry: the boring killers

Two failure modes cause more small-business outages than anything exotic: a disk that quietly fills up over months, and a TLS certificate that expires because whoever set up auto-renewal three years ago has since left. Both are predictable. Both are cheap to alarm on in advance.

UptimeRobot and Uptime Kuma both include certificate and domain expiration monitoring as a standard feature. Point either at your domains, set the warning window to 14 or 30 days, and the certificate problem stops being one.

Disk space just needs a cron job that checks df and pings your alert channel past a threshold: five lines, not a platform.

One alert channel people actually watch

None of the above matters if the alerts land somewhere nobody checks. I've seen shops running five monitoring dashboards with an inbox full of unread alert emails — more visibility on paper than in practice.

Pick one channel someone actually checks — WhatsApp, Telegram, or a phone number — and route every alert into it. Uptime Kuma's notification integrations cover Telegram and ninety-plus other services directly. Healthchecks.io and UptimeRobot both support webhook and email delivery into the same channel.

Alert fatigue is the real failure mode

The instinct once alerting exists is to add more of it — a rule for every metric that can be measured. Resist it. Google's own SRE book is direct about the standard a page has to meet: "every page should be actionable," and it should be "about a novel problem or an event that hasn't been seen before." A page a script could handle on its own shouldn't be a page.

The same book warns what happens once that discipline slips. When pages come too often, "employees second-guess, skim, or even ignore incoming alerts, sometimes even ignoring a 'real' page that's masked by the noise."

The SRE Workbook adds a target worth borrowing at any scale: no more than two paging incidents per on-call shift, so there's time to actually follow up. Rob Ewaschuk's alerting philosophy puts the trade-off plainly: teams should "err on the side of removing noisy alerts," since over-monitoring is harder to fix than under-monitoring.

Three or four alert types that each mean something specific happened beat twenty dashboards that get muted within a month.

Monitoring the server isn't monitoring the business

The last gap costs the most. A server returning 200 OK tells you the process is running, not that it did its job. Checkly's documentation draws this line clearly: uptime monitoring confirms "that a server is up and returning 200 OK status messages," while synthetic monitoring verifies "that the application is operational and responding as expected" by checking the outcome of a real workflow.

You don't need a full synthetic-monitoring platform to apply this at SME scale. A daily script checking whether today's invoice count is above zero, or that today's report landed in the expected folder, is the same principle in five lines.

Wire it into the same heartbeat pattern used for cron jobs and it answers the question that matters: not "is the server alive," but "did the business run today." As I've written on single points of failure in business systems, the checks worth having are tied to what the business would actually miss if it went silent.

What to actually set up

1. External uptime check — UptimeRobot free tier, or self-hosted Uptime Kuma.
2. Heartbeat pings on every cron job that matters — Healthchecks.io or equivalent.
3. Disk space and certificate expiry alarms — mostly built into the tools above.
4. One alert channel, chosen deliberately, that a real person watches.
5. One check on a business outcome, not just server health — did the invoices get made today.

None of this needs a platform contract or a dedicated on-call rotation. It needs about a day to set up, and the discipline to keep the alert list short enough that people keep trusting it.