One application, one machine, one person responsible for it. This is the most common shape of system in the world and the least served by monitoring material, which is mostly written for estates several orders of magnitude larger.
The four questions worth answering
Is it reachable from outside. Is it running out of something. Is the application answering correctly rather than merely answering. Is anything in the log that was not there yesterday.
That is the whole of it. A platform is frequently sold for these four answers, and the platform is not wrong so much as disproportionate.
Reachable is the one that must be independent
Anything running on the machine cannot report that the machine is gone. The check that matters most therefore lives somewhere else, and it is the first thing to set up, before any dashboards. A free hosted check covers it.
Running out of something has a specific shape
Disk, memory, file descriptors, connection limits, and on modern systems, certificate expiry, which is the single most common cause of a sudden outage in small installations.
The article on thresholds argues for measuring time remaining rather than percentage used, and on a single machine that is easy: the growth rate is stable enough that the arithmetic is reliable.
Answering correctly is not the same as answering
A check that requests a page and looks for an expected string catches the failure mode that a status code check misses entirely, which is the application returning a cheerful error page. Writing that check takes five minutes and it is the difference between availability monitoring and the appearance of it.
The person is part of the system
At this scale the monitoring has exactly one recipient, and that recipient has a day job. Any arrangement producing more than a handful of notifications a month will be muted, and the article on deleting alerts explains why nobody will unmute it.
So the alerting decision is a single sentence: what would make this person stop what they are doing. Usually the answer is that the service is unreachable, that something will run out within a day, or that the certificate expires this week. Three rules, not thirty.
The second question is what happens when that person is away. A system with one recipient has no rotation, no escalation and no secondary, which is a real risk and one that a tool cannot solve. Naming a second person, even informally, is worth more than any product on this page.
A hosted external check
- Best forThe first thing installed, on every system of this size
- PricingFree tiers cover a handful of endpoints
- StandoutIndependent of the machine, so it works when the machine does not
- Watch out forOne vantage point, and it tells you nothing about why
A single-node agent with dashboards built in
- Best forPer-host detail without designing any storage
- PricingOpen source; the cost is the resources it uses on the machine it watches
- StandoutHigh resolution, almost no configuration, and useful within an hour
- Watch out forIts history is local, so the machine that died took the evidence with it
Log shipping to somewhere else
- Best forAny system where the log is the only record of what happened
- PricingFree tiers exist; volume-based pricing above them
- StandoutThe log survives the machine, which is the entire point
- Watch out forUnfiltered shipping of a chatty application is how a free tier becomes an invoice
The operating system's own facilities
- Best forTeams who would rather not add a component at all
- PricingFree, and already installed
- StandoutScheduled checks, service supervision and journal retention cover more than people expect
- Watch out forNothing aggregates, nothing alerts by default, and it is entirely on the machine being watched
What not to do at this size
Do not install a distributed storage system to watch one machine. Do not enable a default rule set written for a fleet. And do not build dashboards nobody will open; the article on audiences argues that a dashboard with no decision attached is not neutral, because it still collects and still costs.
The upgrade trigger
Move up when there is a second machine that has to be correlated with the first, or when somebody other than the owner needs to answer a question. Both are real thresholds. Traffic growth by itself is not, and is the reason most small systems end up with tooling built for a scale they never reached.
What we cannot verify
Free tier limits and resource usage figures are published by their suppliers and change; we reproduce none and rank nothing. Whether a given application's log volume fits within a free allowance is answerable by measuring it for a day, which costs nothing.
The short version
- Four questions cover a single-machine system, and a platform is sold for them.
- The reachability check must live somewhere other than the machine.
- Certificate expiry is the most common sudden outage at this scale.
- Check for an expected string, not a status code, or you miss a cheerful error page.
- The machine that died took its local history with it, so ship the log.
- Upgrade when a second machine must be correlated, not when traffic grows.