A team of five running a product has, in practice, a few hours a week of operational attention that is not already committed. Everything in this guide follows from that number rather than from any feature comparison.
The criteria, before any product
Nothing to operate. A highly available time-series database is a system with its own failure modes, and it will fail during the incident it was bought to help with. A team without a platform engineer should not be running one at any price.
It must fail loudly. The characteristic small-team disaster is monitoring that stopped working three weeks ago, which is indistinguishable from everything being fine. Whatever is chosen needs something outside it watching for silence, as the article on polling and agents describes.
Few alerts by default. Five people cannot absorb a default rule set written for an enterprise. A tool arriving with two hundred rules enabled will be silenced within a month, and the article on deleting alerts explains why nobody will ever unsilence it.
A bill that cannot surprise you. Usage-based pricing without a hard limit is a risk transfer to a team with no capacity to absorb it. Either a fixed tier, or a configured cap, or a self-hosted component whose cost is a machine.
Somebody must be able to use it at two in the morning. Query languages that require daily practice are not available to a person who touches the system twice a month.
What the answer usually looks like
Two layers, not one. An external availability check that is independent of everything else, plus one place for metrics and logs that somebody else operates. Anything beyond that is bought when a specific question makes it necessary.
External uptime checking, hosted
- Best forEvery team of this size, as the first thing installed
- PricingFree tiers cover a handful of checks; paid tiers are the cheapest line item you will have
- StandoutIt is outside your infrastructure, so it survives the failure that takes everything else
- Watch out forIt tells you that something is wrong, from one vantage point, and nothing about why
A single-node agent with built-in dashboards, self-hosted
- Best forGetting per-host visibility running in an afternoon with no storage to design
- PricingOpen source; the cost is one small machine and occasional upgrades
- StandoutVery high resolution out of the box with almost no configuration
- Watch out forLong-term storage and cross-host querying are where this class stops, and by then you have grown
A hosted metrics and logs service on a small tier
- Best forTeams that want retention and querying without operating anything
- PricingBilled by ingest, series or host; free tiers are real and the step above them is not small
- StandoutNo database to run, and the retention conversation becomes a setting rather than a project
- Watch out forVolume growth arrives as an invoice, so a cap or an alert on your own usage is not optional
A self-hosted metrics stack
- Best forTeams with a platform engineer, or a hard requirement that data stays in-house
- PricingFree to license; the cost is the person who understands it
- StandoutComplete control, no per-series pricing, and a large ecosystem
- Watch out forIt is a distributed storage system, and a team of five is choosing to operate one
A single commercial platform covering everything
- Best forTeams who would rather spend money than attention, with a budget that can take it
- PricingThe most expensive option per unit, and the least expensive in hours
- StandoutOne agent, one place to look, and correlation between classes you would not build yourself
- Watch out forCost scales with growth and with enthusiasm, and unpicking it later means re-instrumenting
The order that works
Install the external check first, on day one, before anything else. It is the only component that helps on the day the rest of the setup is part of the problem.
Then one place for metrics and logs, chosen by which of the two questions the team asks more often. Then stop, and let the next purchase be triggered by a question that could not be answered rather than by a feature that looked useful.
What to skip at this size
Distributed tracing, until there is more than one service and a latency question that metrics genuinely cannot settle. Anomaly detection, which needs a longer history than the system has and which the article on thresholds argues will absorb slow degradation anyway. And any product requiring a dedicated administrator, which is a role this team does not have and will not create.
What we cannot verify
Free tier limits, pricing structures and packaging change frequently and are set by the vendors; we reproduce no rates and no product is ranked here. The characterisations above describe classes of option as documented by their publishers, and we have tested none of them. What your own team can carry is answerable by asking who would be woken and what they would be able to do, which costs nothing and is rarely done before a purchase.
The short version
- The binding constraint is a few unspent hours a week, not a feature list.
- A team without a platform engineer should not operate a distributed storage system.
- Monitoring that stopped three weeks ago looks exactly like everything being fine.
- A default rule set written for an enterprise will be silenced within a month.
- Install the external check first, because it survives the failure that takes the rest.
- Let the next purchase be triggered by an unanswerable question, not by a feature.