Small-System Monitoring: The Checks That Matter

Start monitoring a small system with four checks: the site is reachable, scheduled jobs finish, disks have space and certificates remain valid. Add a business check, such as whether invoices were actually created. Send alerts to a named responder. This is an affordable starting point; additional checks should follow the risks and workflows of your business.

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. For a company running three to eight servers, those features may exceed the initial monitoring need — 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

Start with the four checks above, then add checks for the actual failure modes. 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.

Add an alert channel with a named responder, then review gaps, including business-process failures.

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 no credit card required. Check the available monitor types, notification channels, and certificate/domain expiry features when signing up; some features require a paid plan.

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.

Use a completion heartbeat: the job reports success, and a missing report raises an alert. 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 can help monitor certificate expiry. Check the selected plan and version for certificate and domain expiry support; they are separate capabilities. Point either at your domains, set the warning window to 14 or 30 days, and test both the warning and renewal process.

A small scheduled check can inspect disk usage with df and notify your alert channel above a threshold. Test its failure handling and also monitor whether the check itself runs.

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.

These checks provide a modest starting point. Agree who responds, how alerts escalate, and what setup and maintenance the actual system needs.